C++ Logo


Advanced search

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

From: Justin Bassett <jbassett271_at_[hidden]>
Date: Tue, 13 Jul 2021 20:44:04 -0700
I've attempted to address issues in the attached latest draft. In
particular, the Tony Table has changed slightly to be more straightforward,
with some discussion after it. I also included some discussion on why this
change should be included despite nullfoo being not too much shorter than
the foo<T>() constructors. With respect to my statement that I don't feel
the Tony Table shows exceedingly strong motivation for the paper, I do feel
that it shows good motivation, and that with this paper proposing such a
minor change, it's never going to have an immense effect in diffs.

I realized from what Nevin said that I appear to have assumed the rationale
for removing nullptr < nullptr as "When removing ptr > nullptr, there was
no longer any real appeal to nullptr > nullptr because the relational
operators are meaningless in isolation." It would definitely be better to
have the actual rationale rather than my assumed rationale.


On Tue, Jul 13, 2021 at 11:13 AM Nevin Liber via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, Jul 9, 2021 at 5:12 PM Jens Maurer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#583
>> If there is some feeling or use-case that nullptr < nullptr
>> should be well-formed, that could be proposed.
> What was the rationale for removing it? What was the rationale for
> keeping nullptr == nullptr? That rationale is what a paper would have to
> argue against. CWG 583 and 1512 talked about problems with heterogeneous
> comparisons, not homogeneous comparisons.
> --
> Nevin ":-)" Liber <mailto:nevin_at_[hidden]
> <nevin_at_[hidden]>> +1-847-691-1404
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2021-07-13 22:44:24