Re: [boost] Mother of all Variants

On Wed, 17 Apr 2019 at 14:42, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

wt., 16 kwi 2019 o 23:57 Richard Hodges via Boost 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@lists.boost.org> 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@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

_______________________________________________ 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@gmail.com office: +442032898513 home: +376841522 mobile: +376380212