Date: Sat, 10 Jul 2021 00:17:38 +0300
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().
> 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().
Received on 2021-07-09 16:17:51