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.