Re: [boost] variant2 never empty guarantees

Subject: Re: [boost] variant2 never empty guarantees
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-06-08 23:05:47

On 9/06/2017 01:22, Andrzej Krzemienski wrote:
> 2017-06-08 15:01 GMT+02:00 Peter Dimov:
>>> I'm not sure I understand this fully; could you please explain from what
>>> expressions, and under what conditions, you expect the strong guarantee?
>>>
>>>      variant<X, Y> v1, v2;
>>>      X x;
>>>
>>>      v1= v2; // do you expect strong guarantee here?
>>>      v1 = std::move(v2); // here?
>>>      v1 = x; // here?
>>>      v1 = std::move(x); // here?
>>>      v1.emplace<X>(); // here?
>>>
>>
>> Anyone? This is a genuine inquiry. How can I give you strong guarantee if
>> you don't tell me when and where you want it?
>>
> 
> Maybe nobody needs the strong guarantee? This is definitely the case for my
> programs. I put variants in different containers. But if exception is
> thrown while modifying them I am destroying the entire data structure. I do
> not need the previous state. If I cannot put the new one, I cannot proceed
> anyway.
> 
> (I am not saying such guarantee is useless. I just observe that the need
> occurred in my programs.)

The only case that I can think of at the moment is for something like a 
state machine, where each type in the variant is a possible state and 
the current value is the current state.  If a transition fails via 
throwing from the new state constructor then presumably the state 
machine should remain in the previous state.

Having said that, the proposed implementations of strong guarantee 
wouldn't work for that case anyway, since that sort of state machine 
also generally assumes that the current state destructor is run strictly 
before the new state constructor, and that wouldn't be the case if you 
stacked a backup in case of exception.  (Mind you, it also wouldn't be 
the case even for basic assignment; they'd have to explicitly assign a 
none_t or something first to make that happen.)  So the right place to 
handle that guarantee is in the state machine transition machinery, not 
in variant itself.

People generally require that for x = f() then if f() throws x should be 
unmodified (which is automatic based on how the language works); if it's 
the assignment itself that throws then things are usually beyond 
recovery anyway, since assignment is not really expected to throw for 
any reason other than out of memory.