Re: [boost] variant2 never empty guarantees (was: Re: Outcome/expected/etc/etc/etc)

Subject: Re: [boost] variant2 never empty guarantees (was: Re: Outcome/expected/etc/etc/etc)
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2017-06-16 20:11:22

On Fri, Jun 16, 2017 at 5:22 AM, Andrzej Krzemienski via Boost
<boost_at_[hidden]> wrote:
> 2017-06-14 19:10 GMT+02:00 Peter Dimov via Boost <boost_at_[hidden]>:
>
>> Andrzej Krzemienski wrote:
>>
>> Now I realize this all means the types inside variant need to be movable.
>>> This will not be a problem in most of the cases, but does it mean I cannot
>>> use variant2 with non-movable types?
>>>
>>
>> You can, it will double-buffer to keep emplace strong. Or you can use
>> valueless.
>>
>> All types nothrow move constructible -> single buffer;
>>
>> Otherwise, first alternative is valueless -> single buffer;
>>
>> Otherwise -> double buffer.
>
>
> So, If I got all this right:
>
> * All types nothrow move constructible -> single buffer, requires
> MoveConstructible;
> * Otherwise, first alternative is valueless -> single buffer (no
> MoveConstructible);
> * Otherwise -> double buffer (no MoveConstructible).
>
> Is that correct?
>
> Some other thoughts:
>
> When valueless is required as the first type, it also implies that the
> default constructor of variant puts it into valueless state, which some
> might find useful, but others inferior to std::variant. Would it be
> possible to also assign a special meaning to putting `valueless` at the
> end, which would assign semantics of std::variant?

I think if you have the valueless state, and you accept that you might
fallback to that state,
then there is a high likelihood that you want the default constructor
to start in the valueless state.
If you want to start in some other state, initialize it explicitly.

>
> Maybe the choice how you want to implement the assignment should be
> explicitly controlled by the users (in form of a policy)? You could still
> provide the defaults based on properties of the types, but it looks to me
> sometimes people might want to override the defaults. For instance, we have
> seen examples where I want strong guarantee on assignment even when T does
> not offer one. Or to put it differently, it may be that this double
> buffering may be useful on its own, even outside the variant.
>

I think you are now treading on feature-creep.  Variant should do its
job (switch types), not the job of others.
Maybe we need a strong<> type that magically makes any type have the
strong guarantee (typically by double buffering).

> Regards,
> &rzej;
>

Tony