Re: [boost] Mother of all Variants

Subject: Re: [boost] Mother of all Variants
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-17 12:42:17

wt., 16 kwi 2019 o 23:57 Richard Hodges via Boost <boost_at_[hidden]>
napisał(a):

> Are there real-world examples of well-designed classes who's move
> assignment operators throw?
>
> I think if I saw that in a code review I'd be inclined to demand a
> different design choice.
>
> Is there a good reason that variants should support such classes?
>

Some implementations of std::list throw from their move constructors and
default constructors. I understand that the implementation is easier if
even an empty list has a dummy node, which requires allocation.

Regards,
&rzej;

>
> On Tue, 16 Apr 2019 at 17:42, Robert Ramey via Boost <
> boost_at_[hidden]>
> wrote:
>
> > 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
> >
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
> --
> Richard Hodges
> hodges.r_at_[hidden]
> office: [phone]
> home: [phone]
> mobile: [phone]
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>