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

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Peter Dimov (lists_at_[hidden])
Date: 2019-03-01 00:16:34

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.