Boost logo

Boost :

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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at