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

pt., 1 mar 2019 o 01:17 Peter Dimov via Boost 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.d...

...

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 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