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

On Fri, Jun 16, 2017 at 5:22 AM, Andrzej Krzemienski via Boost wrote:

2017-06-14 19:10 GMT+02:00 Peter Dimov via Boost :

...

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