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

Subject: [boost] [variant2] Need rationale for never-empty guarantee
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-02-28 13:13:38

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.

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

I think that this question should be addressed in the documentation.

Regards,
Andrzej