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

-----Original Message----- From: Boost On Behalf Of Niall Douglas via Boost

...

variant2 also only provides *basic* exception safety guarantee: you can be assigning a variant containing type B to a variant containing type A and end up with variant containing type C. Here's an example: https://wandbox.org/permlink/AObFiUKgeXIEiXQa

I just don't get why variant2 would set a state of C when it had state A, and setting state B failed. It should have spotted the lack of common noexcept move, employed double buffers, and alternated between them such that state A is untouched should setting state B fail.

If it's going to do weirdness like setting state C out of the blue, then better dispose entirely any double buffered implementation as not adding value.

I have to agree with Niall here (at least partially). When I have a variant that holds value "a" of type A and I assign a value "b" of type B to it, I expect to end up either with a, b or an error state if such a state is modeled by the variant type *). Falling back to a completely unrelated type C seems very surprising to me. Even more confusing would probably be the case if A or B happen to be the "fallback" type and I'd end up with a default constructed A or B instead of either a or b. *) I prefer an error state that is part of the variant type like valueless_by_exception. I'm also fine with a "fallback state" that is explicitly blessed like monostate. But it should not be the first type from the typelist that happens to be noexcept default constructible. In summary: Just as stated by Niall, I'd prefer either getting the strong exception guarantee or an explicitly modeled error state. On a related but different topic: I think it would be useful if one was able to statically assert if a variant2 type uses double buffering or not. Best Mike