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