|
Boost : |
Subject: Re: [boost] Mother of all Variants
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-04-16 15:42:18
On 4/16/19 5:41 AM, Larry Evans via Boost wrote:
> 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 ...
Right. We could have it both ways. That is the mother of all variants
could be used to generate a custom type given the requirements. For
those who don't want/need to delve into all the details, we provide a
list of specialization for commonly used variants which would probably
address 99.9% of users needs.
Robert Ramey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk