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

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2019-03-02 18:40:04

AMDG

On 3/2/19 11:25 AM, Niall Douglas via Boost wrote:
>>> Thus I would hold that, unless there is a *very* good reason why not, so
>>> should std::variant propagate the strong guarantee where it is able to
>>> do so. To my knowledge, there is no good reason that is does not, as
>>> proven by Peter's variant2.
>>
>> Hold on. Most standard library types *do not* provide strong exception
>> safety guarantee on assignment. It is only the subset of STL containers
>> that are implemented as pointers, such as std::vector or std::list.
> 
> You see, I would consider any union-based storage as in the same
> category. By definition union-based storage must contain a "pointer" to
> the correct way to interpret that union-based storage.
> 

I don't understand this.  Andrzej says pointers and
means it literally: T*.  You say "pointers" and
I have no idea what you mean by it and what relation
it has to exception safety.

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

variant2 won't use double buffering in this example.

In Christ,
Steven Watanabe