C++ Logo


Advanced search

Re: nullptr_t and nullopt_t should both have operator<=> and operator== to enable the *_with concepts

From: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Date: Fri, 9 Jul 2021 23:33:04 +0300
On Fri, 9 Jul 2021 at 22:55, Ville Voutilainen
<ville.voutilainen_at_[hidden]> wrote:
> On Fri, 9 Jul 2021 at 22:18, Justin Bassett via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > I agree that LSP is incorrect. That's a symptom of me writing this draft while being a bit too tired.
> >
> > See the updated draft with motivation updated. It also includes a brief Tony table.
> Thanks! I think the example could use a bit of explanation, because..
> *mirthless laughter* so all this boils down to
> equality_comparable_with<T, U> managing to require that
> T and U are individually equality_comparable, even though all we're
> doing here is a heterogeneous comparison.
> equal_to superficially looks like it can do such a heterogeneous
> comparison, but it can do it only if the
> heterogeneous arguments are themselves equally_comparable, which is an
> operation the predicate never
> uses, so it's a bit beyond me why it's required by the algorithm, but
> ranges do a lot of this "be regular or you won't work".
> Presumably the same goes for the upper_bound example.
> The improved motivation is highly useful, thanks again - this makes
> the proposal far more palatable, and flips my
> initial take on "why bother" to "seems like a decent fix". :P Please
> consider adding an explanation of the example,
> so that it doesn't take a test run of it and reading through the
> concept satisfaction errors. Perhaps even provide
> an online compiler link, although the explanation would probably be
> much more useful.

Here's a commented online compiler link:

Please also add SG9 (the Ranges Study Group) to the target audience,
and also EWG and LEWG.
What we have here is an interesting case of constraining a
heterogeneous comparison so hard
that to make it work reasonably well with nullptr, a language change
is needed, as well as a library change
to nullopt. That should give various audiences some pause.

It also seems hard at least for me to work around this by passing a
projection to the range algorithm,
that's quite complex and quite verbose, and still doesn't remove the
problem... perhaps that's worth
mentioning as well.

Received on 2021-07-09 15:33:17