Re: [boost] [variant2] Need rationale for never-empty guarantee

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Nevin Liber (nevin_at_[hidden])
Date: 2019-03-04 23:30:27

On Mon, Mar 4, 2019 at 3:07 AM Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> nullopt_t was a compromise: the Committee didn't feel comfortable with
> introducing a generic boost::none_t with this name with well defined
> semantics (comparability, ordering, interaciotns with nullptr_t) that soon
> in the process, so we provided something that was supposed to be a
> temporary solution, a tag (like std::piecewise_construct) whose only
> purpose is to indicate an intention to initialize std::optional to a state
> of not containing a value. Now std::monostate has taken the role of
> boost::none_t. It would make sense to use it in std::optional:
>
> std::optional<int> oi = std::monostate{};
>

Which breaks this case:

std::optional<std::variant<std::monostate, int>> ov = std::monostate{};

Having to spend any brain power at all to figure out the corner cases makes
it not worth having a universal "none" type.  You aren't just burdening
library designers; you are burdening the users too.
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden] <nevin_at_[hidden]>>
[phone]