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

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Gavin Lambert (boost_at_[hidden])
Date: 2019-03-04 23:58:17

On 5/03/2019 12:30, Nevin Liber  wrote:
> 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.

That's not really a sensible use case, though, because a monostate 
variant is equivalent to an empty optional.  It makes very little sense 
to intentionally nest them.

(Although of course it could happen as a result of composition of 
generic code, so it should not be a compile error.)

It seems more burdensome for users to have multiple different ways of 
saying "no value", and having to remember which one to use with each type.

In some respects it annoys me that nullopt_t was introduced instead of 
reusing nullptr_t -- but that case is more justifiable, as the language 
already distinguishes between "pointers" and "not-pointers" elsewhere.