Boost logo

Boost :

Subject: Re: [boost] Mother of all Variants
From: Larry Evans (cppljevans_at_[hidden])
Date: 2019-04-16 12:41:25

On 4/16/19 4:28 AM, Jonathan Müller via Boost wrote:
> On 16.04.19 03:51, Robert Ramey via Boost wrote:
>> I'm way out of my depth in the variant discussion.  Seems to me it
>> revolves around all the trade offs regarding design choices.  Could we
>> perhaps decide not to decide.  Suppose we create a type which looks like:
>> template<
>>    bool BasicGuaranteeSupported,
>>    bool StrongGuaranteeSupported,
>>    bool EmptyStateProhibited,
>>    bool AssignmentSupported,
>>    bool MoveSupported,
>>    class T ...
>>  >
>> struct mother_of_variants{
>>    // some trivial mp11 code
>> };
> I did something similar back when I did type_safe::variant: You have a
> `VariantPolicy` that controls whether the variant can be empty and a has
> a `change_value()` function that switches the type in whatever way it
> seems fit.
> With that I have a `rarely_empty_variant` that is like `std::variant`,
> a `never_empty_variant` that assumes move is no-throw (and calls
> terminate() if they throw) and an `optional_variant` that fully embraces
> an empty state.
> At the time I thought it was a good trade-off, but haven't re-evaluated
> it since then.

I like this; however, years ago there was some argument
about how providing such a policy for smart pointers
would be confusing to users. However, I didn't really
agree with that argument and the alternative is, AFAICT,
not much better:
   std::variant, or boost::variant2 or libx::variant3 or ...

Boost list run by bdawes at, gregod at, cpdaniel at, john at