Subject: Re: [std-proposals] What happened on "Null safety" in p0946r0 about p <=> nullptr
From: Jake Arkinstall (jake.arkinstall_at_[hidden])
Date: 2019-12-05 05:13:23
Ah of course. I'm thinking of a comparison that demands two identical
argument types, which isn't necessarily the case.
Im just thinking from the memory model point of view. A nullptr is
implicitly convertible to a fictional object at address 0. Valid pointers
represent objects at address >0. So if one has a reason to be comparing
pointer addresses, I'd have thought that it would be in their interest to
make it consistent with that picture - for exactly the same reason that it
is in our interest to allow a strong ordering upon unsigned comparison with
0, even though the result is restricted to two possible values (and != 0
But at the end of the day, that only requires a cast. p <=>
static_cast<decltype(p)>(nullptr) would have the effect described above,
and has the benefit of making it more awkward to do something foolish by
On Thu, 5 Dec 2019, 10:51 Kazutoshi Satoda, <k_satoda_at_[hidden]> wrote:
> On 2019/12/05 18:55 +0900, Jake Arkinstall via Std-Proposals wrote:
> > Out of pure interest, what is the problem in returning a strong ordering
> > with nullptr always being less than p, unless p is a nullptr too, in
> > case the result would be equality?
> If it can be used only for equality, expressing it with
> equality operators (==, !=) will be always better. Equality operators
> express the meaning clearer, shorter, and don't need #include <compare>.
> > As nullptr is implicitly convertible to any pointer, that's the outcome
> > that one might expect.
> It is inconsistent with other relational operators (like p < nullptr,
> which is ill-formed).
> > But if not, then ill formed is infinitely better than unspecified IMO.
STD-PROPOSALS list run by email@example.com
Standard Proposals Archives on Google Groups