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

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-03-01 08:03:58

pt., 1 mar 2019 o 01:17 Peter Dimov via Boost <boost_at_[hidden]>
napisał(a):

> Andrzej Krzemienski wrote:
> > Hi Peter,
> > Thank you for writing and sharing this implementation of variant.
> >
> > I am sorry if I am bringing back an issue that has been already
> discussed
> > and solved before, but I do not understand the rationale behind doing
> > compromises in order to provide the never-empty guarantee.
> >
> > The short rationale provided in Boost.Variant library:
> >
> https://www.boost.org/doc/libs/1_69_0/doc/html/variant/design.html#variant.design.never-empty
> > was provided before we got C++11 the moved-from state in the language.
> > Today, it should come as no surprise to programmers that a type might be
> > in a "moved from" state where only a limited interface of an object can
> be
> > used.
>
> C++11 introduces no such "moved-from" state. After a move, objects are not
> in a special state. The desire to have variant<X, Y, Z> contain one of X,
> Y,
> or Z, is as valid today as it was when Boost.Variant was developed.
>
> > The guarantee provided by variant's assignment is not a strong exception
> > safety guarantee: it is possible that my variant has value A, I want to
> > assign value B, and (due to an exception) I end up with value C.
>
> That's correct. Strong guarantee requires double buffering when two or
> more
> of the alternatives have a throwing move constructor. This would affect
> significantly more of the real-world cases than the current scheme, which
> doubles only occasionally.
>
> > If this happens, the only thing I can reasonably do is to either abandon
> > whatever I was doing or reset the variant to the state that I need. So
> the
> > guarantee that it is not left empty does not seem to be of much use. But
> > the cost to be paid is noticeable.
>
> Well, if you want a variant without this guarantee, there are plenty to be
> found. Those who don't, however, have no options at present.
>

So, does the following recommendation correctly capture the design goals
for boost::variant2?

If you require the never-empty guarantee (and accept the costs) use
boost::variant2.
If you do not require the never empty guarantee use std::variant.

(For the sake of the discussion, I do not consider the additional
conversions offered by variant2).

Also, I am not entirely satisfied with the reply, "those who want this
guarantee". Could you, or anyone else, give me a real-world use case where
a never-empty guarantee is needed, but a strong exception guarantee is not?
It might be just my lack of imagination, so I would appreciate any help
understanding this.

Regards,
Andrzej