Re: [boost] [review][variant2] Variant2 Review Starts April 1

Subject: Re: [boost] [review][variant2] Variant2 Review Starts April 1
From: Larry Evans (cppljevans_at_[hidden])
Date: 2019-03-26 18:28:49

On 3/26/19 1:10 PM, Matt Calabrese via Boost wrote:
> On Tue, Mar 26, 2019 at 2:03 PM Larry Evans via Boost
> <boost_at_[hidden]> wrote:
>>
>> On 3/26/19 12:08 PM, Andrzej Krzemienski via Boost wrote:
>> [snip]
>>>> As long as there are non-trivial trade-offs for any type/template, there
>>>> will be reasonable users who would opt for different trade-offs when in
>>>> different domains. We just have to decide which combinations of the
>>>> trade-offs are worth collecting into a facility that is present in boost or
>>>> the standard or elsewhere.
>>>>
>>>
>>> True. And maybe names of different variants of variant should reflect the
>>> different trade-offs. Maybe noempty::variant rather than
>>> variant2::variant?
>>>
>>
>> What about:
>>
>>     template<typename... T>
>>     struct boost::variant2<T...>: std::variant<T...>
>>     { ... };
>>
>> ?
>>
>> After all, isn't boost::variant2<T...>
>> simply more restrictive than std::variant<T...> in that
>> boost::variant2 has the
>> the never-valueless requirement
>> but std::variant does not.
> 
> That cannot work for a variety of reasons. Even if it were possible to
> implement it that way and we were okay with a dependence on the
> standard library having std::variant, it also would mean that
> interactions with the variant via the base class would be able to
> break the child class's never-empty guarantee (meaning it would not be
> a guarantee). So an inheritance relationship here would not make
> sense.
> 
Good point.  Then how about:

template<typename... T>
struct boost::variant2<T...>
: private std::variant<T...>
{
    using std::variant<T...>::
      //{ all member functions **not** breaking never-valueless};
    //{ over-rides for those member functions that
        **do** break never-valueless}
    //}
};