Boost logo

Boost :

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}

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