Subject: [std-proposals] What happened on "Null safety" in p0946r0 about p <=> nullptr
From: Kazutoshi Satoda (k_satoda_at_[hidden])
Date: 2019-12-05 02:30:53
I found that, in the latest draft n4842, three-way comparison (<=>)
between an object pointer and a null pointer constant (p <=> nullptr)
yields unspecified result of type std::strong_ordering.
> If the composite pointer type is an object pointer type, p <=> q is of
> type std::strong_ordering. If two pointer operands p and q compare equal
> (7.6.10), p <=> q yields std::strong_ordering::equal; if p and q compare
> unequal, p <=> q yields std::strong_ordering::less if q compares greater
> than p and std::strong_ordering::greater if p compares greater than q
> (7.6.9). Otherwise, the result is unspecified.
I think it doesn't make sense and want p <=> nullptr be ill-formed.
Looking for issues already reported, I found https://wg21.link/p0946,
which had a section "Null safety", saying almost exactly what I think:
> The resolution of core issue 583 made relational comparisons against
> null pointer constants ill-formed. Such constructs have always been
> ill-formed in C, and appear likely to have only ever been valid in C++
> due to a wording oversight.
> However, the <=> operator oddly produces a std::strong_ordering result
> when comparing a null pointer constant against an object pointer,
> producing std::strong_ordering::equal when the pointer is null and an
> unspecified value (which could even be std::strong_ordering::equal!)
> otherwise. This seems to also be merely a wording oversight.
But the changes in the wording paper https://wg21.link/p1120 for p0946,
which had been adopted at 2018-06, didn't fix the above "Null safety"
issue, and the issue still remains in the latest draft.
Was it an oversight? Or something new was found to keep it unspecified?
STD-PROPOSALS list run by email@example.com
Standard Proposals Archives on Google Groups