Re: [boost] [outcome] Exception safety guarantees

Subject: Re: [boost] [outcome] Exception safety guarantees
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-28 23:38:00

>> So the strong never empty guarantee implemented by both Outcome and
>> Expected means that 'a' still contains its original A untouched and
>> undamaged. 'b' also contains its B untouched and undamaged, though that
>> is up to B's copy constructor.
>>
> 
> I wonder if this is possible. In `result` you have a T an an
> error_code_extended. If you are assigning to an errored result:
> 
> ```
> outcome<T> o = make_errored_result(xxx);
> outcome<T> v = T{yyy};
> 
> o = v;
> ```
> 
> What do you do? First you need to destroy the error_code_extended stored by
> `o`. Then you try to copy-construct T in the same storage. If it fails, you
> have no error to return to: you have just destroyed it, and possibly
> overwrote the storage.
> 
> So I fail to see how you can implement a strong guarantee for the
> assignment, unless you apply no-throw restrictions on type T.

It's very straightforward.

If the existing state's type is nothrow move but the new state's type is
throwing move/copy, you move it onto the stack. Then you clear storage,
and assign in the T. If that throws, you restore the stacked previous state.

If the existing state's type is throwing move and the new state's type
is nothrow move, you destruct, clear storage, and do the assignment.

Only if the existing state's type is throwing and the new state's type
is throwing is there a problem. That's why I said earlier that to
implement the strong never empty guarantee without additional storage,
all but one of a variant's types must be nothrow move.

Does this make sense?

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/