Re: [boost] Outcome/expected/etc/etc/etc

Subject: Re: [boost] Outcome/expected/etc/etc/etc
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-05 18:05:00

On 05/06/2017 15:23, Gottlob Frege via Boost wrote:
> On Mon, Jun 5, 2017 at 7:57 AM, Peter Dimov via Boost
> <boost_at_[hidden]> wrote:
>> Gottlob Frege wrote:
>>
>>> Some days I'm like "man just accept empty, it would be a simple API", but
>>> then I think "it is stupid for variant<int, double> to be empty". Other days
>>> I think "just double buffer when necessary" (I assume that's your direction
>>> Peter?), but then I think "I don't want double-buffering variant<list,
>>> vector> to go on/off based on whether I use MS std vs libc++ etc" and also
>>> "I don't want double buffering for cases that only happen in theory, not in
>>> practice".
>>
>>
>> That is my direction, yes. My variant uses double storage when (1) not all
>> types have noexcept move constructors and (2) there isn't a noexcept default
>> constructible type in the list.
>>
> 
> So converting a Circle to a Triangle might result in a Rectangle,
> because Rectangle is the fallback?
> I'd rather have double buffering or valueless_by_exception.  ie
> correctness or acknowledgement of error.  Not silent incorrectness.

I hate with a passion any possibility of a variant changing its state
without me explicitly telling it to do so. The only tolerable state a
variant should ever choose on its own is empty/valueless.

I repeat my suggestion that for variant2:

1. If at least all types minus one have nothrow move construction, you
get the strongest possible never empty never change guarantee.

2. If the user is dumb enough to supply more than one type with a
throwing move constructor, they get the current C++ 17 variant valueless
by exception semantics i.e. go valueless if changing state threw an
exception and the previous state threw an exception on attempt to restore.

3. We thus never double storage.

4. And we never, EVER change state silently to something the user did
not explicitly ask for.

Niall

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