Re: [boost] Strong guarantee variant (Was: Outcome/expected/etc/etc/etc)

Subject: Re: [boost] Strong guarantee variant (Was: Outcome/expected/etc/etc/etc)
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-08 07:16:06

2017-06-06 14:20 GMT+02:00 Peter Dimov via Boost <boost_at_[hidden]>:

> Niall Douglas wrote:
> On 06/06/2017 12:14, Peter Dimov via Boost wrote:
>
>> > I don't understand of what value is a guarantee that is strong when you
>> > change type, but basic if you don't, but perhaps I'm missing something >
>> here.
>>
>> My opinion would be that most users would expect a variant object to not
>> be involved with the type being worked with, certainly not overriding its
>> implementation. If the variant's state is pointing to type Foo, and I
>> assign to the variant, it's 100% onto Foo's assignment operators what
>> happens next, including any throwing or whatever guarantees.
>>
>
> That would mean the basic guarantee, for nearly all types in existence for
> which the assignment can fail.
>
> Types don't generally provide the strong guarantee on assignment as it
> doesn't compose. If type T has strong assign, type U has strong assign,
> struct { T t; U u; } no longer does. So it's more efficient to just do
> basic everywhere, which does compose, and then at the specific point you
> want the strong guarantee, use f.ex. the copy and swap trick to get it.
>

I think the reasoning behind Niall's position is that a type `X` can have a
custom guarantee: upon its assignment it guarantees that after a throw the
type is either unchanged or goes to fallback state `0`. This guarantee is
stronger than basic, and weaker than strong. It adds no value in generic
components like STL, but does add value when you are dealing only with your
specific type `X`.

Now, the user may expect that `variant<X, others...>` preserves this custom
guarantee when two variants happen both to store an `X`.

Regards,
&rzej;