Re: Mother of all Variants

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2019-05-30 12:33:41

On Wed, 17 Apr 2019 at 14:42, Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> 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.
>
>
I don't wish to sound too challenging but it seems to me that it would
better for the community is the maintainers of these rogue list types got
their act together.

People who are looking for the easy way out have no business maintaining
the fundamental building blocks of our entire universe.

In de-facto reality, I would be stunned to find code that expects and
gracefully manages an exception during a move construction. I would put a
lot of money behind a bet that says anything you find in production today
will either `abort` or head off into UB land if this happens. If anyone has
designed a class to throw from its move constructor, they need to be sent
for immediate re-education.

It seems to me that making variants (and indeed everything!) demand nothrow
moves will make them safer, because rogue programs will observably and
predictably crash if the  unthinkable should happen.

> 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
> >
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Richard Hodges
hodges.r_at_[hidden]
office: [phone]
home: [phone]
mobile: [phone]