Boost logo

Boost :

Subject: Re: [boost] Strong guarantee variant (Was: Outcome/expected/etc/etc/etc)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-06 11:53:25


On 06/06/2017 12:14, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
>> > I wonder whether the people who insist on the strong guarantee on >
>> assignment realize that when the variant holds a vector, and you
>> assign > it a vector, assignment delegates to vector<>::operator= and
>> as a result > you get the basic guarantee because that's what all
>> standard types > provide.
>>
>> I'd expect nothing else. No state change means you always pass through
>> to operator=().
>
> 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.

Let me put this another way round: I definitely want Variant to offer
better than or *equal* to guarantees to the operation I am performing to
the current state. I do NOT want universally stronger guarantees if the
cost is:

1. Calling a different, unexpected operator. If I call operator=() on a
variant with state Foo, I expect Foo::operator=() to be called. If Foo
doesn't implement operator=(), I expect the variant's operator=(Foo) to
fail to compiler. That's intuitive.

2. If I call operator=() on a variant with state not Foo, I expect the
old state to get destructed and Foo's move/copy constructor to be
called. That's intuitive.

3. I do NOT expect default constructors of unrelated types to Foo to
EVER be called.

4. I do NOT want any additional runtime overhead whatsoever if all the
variant's types have nothrow move constructors and nothrow destructors.

So, any noexcept on operator=() is going to be the lowest common
denominator, if two or more types are operator=() noexcept(false), so is
the variant's operator=().

Niall

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk