On Fri, Jul 9, 2021 at 12:57 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Fri, 9 Jul 2021 at 19:51, Nevin Liber via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On Fri, Jul 9, 2021 at 10:23 AM Ville Voutilainen via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>
> >> These tag types are not for general programming, they're for use as
> >> constructor arguments.
> >
> >
> > It is more than just that, as we have the full set of heterogeneous
> comparisons between optional<T> and nullopt_t, as well as smart_ptr<T, ...>
> and nullptr_t. It is inconsistent that they themselves don't have a full
> set of homogeneous comparisons, especially given how simple it is to define
> them.
>
> Inconsistent it may be, sure, but making it consistent has a possible
> semantic cost for programmers; if comparisons between two nullopts
> have no practical uses, it's questionable whether they should be made
> well-formed, because they can become something that papers
> over logic errors in code.
>

That same argument applies to comparing two nullptr_t objects, and yet we
can equality compare them.

I would rather we had a reason *for* the inconsistency, but given that the
inconsistency is status quo, that ship sailed long ago.

If such a proposal were to appear, I would likely vote strongly for it.
But hopefully such a proposal wouldn't take all that much committee time,
one way or another.

-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden] <nevin_at_[hidden]>>
+1-847-691-1404