C++ Logo

std-proposals

Advanced search

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

From: Barry Revzin <barry.revzin_at_[hidden]>
Date: Fri, 9 Jul 2021 16:20:25 -0500
On Fri, Jul 9, 2021 at 4:17 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Sat, 10 Jul 2021 at 00:11, Barry Revzin <barry.revzin_at_[hidden]> wrote:
> > Second, std::nullopt_t isn't just a tag type. It largely behaves as an
> instance of optional<T>, for all T. It's not exactly that, because C++
> doesn't work that way (as opposed to in Rust where None actually is an
> instance of Option<T>, for whichever T), but it's close enough. In that
> sense, comparing nullopt_t to nullopt_t makes as much sense as comparing
> any other optional<T> to any other optional<T> (and arguably more sense
> than comparing an optional<T> to either a T or an optional<U>).
>
> The problem with that "largely" is that it sure doesn't behave like an
> instance of optional<T> for things that largely make an optional tick,
> like .has_value(), operator*, .value() and .value_or().
>

Yeah, but it's constructible, assignable, and comparable... which, as
people often tell me, should actually mean that they're "the same."

Also, these functions could easily be provided to just be: false, UB,
throw, and just return the provided argument, accordingly.

Barry

Received on 2021-07-09 16:20:39