Boost logo

Boost :

Subject: Re: [boost] Mother of all Variants
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2019-04-16 21:56:59


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?

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: +442032898513
home: +376841522
mobile: +376380212

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk