Re: [boost] [review][variant2] Variant2 Review Starts April 1

Subject: Re: [boost] [review][variant2] Variant2 Review Starts April 1
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-03-26 17:08:44

wt., 26 mar 2019 o 17:46 Matt Calabrese via Boost <boost_at_[hidden]>
napisał(a):

> On Mon, Mar 25, 2019, 12:33 PM degski via Boost <boost_at_[hidden]>
> wrote:
>
> > In my view there can only be one objective with boost varant2,
> > and that is if it is decided [here] that it is (much) better than the
> > current std::variant, the C++20 std::variant should be/become the
> proposed
> > boost::variant2.
> >
>
> I don't think that's realistic based both on how the committee operates and
> specifically on what happened with std::variant standardization. The
> high-level design approach that variant2 takes was discussed during
> standardization, but it differed from the proposal that was moving forward
> and did not get consensus. Even if the standards committee were to now
> decide that std::variant *should* be changed, it would be a breaking change
> of a kind that the committee has historically had a hard time doing, even
> when it comes to fixing design bugs. I just don't see std::variant changing
> here.
>
> Separately, I don't think it is a problem that there are multiple
> variant-like type implementations. Over the past couple of years, people
> seem to have become a little bit too enamored with the notion of a
> "vocabulary" type and take it further than is healthy. std::variant can
> still be the "vocabulary" type in its current form and that's okay. We have
> multiple sum types in boost and in the standard and in proposals (optional,
> variant, expected). That's fine just as it is fine (and healthy) that we
> have multiple containers. std::variant can still be a "vocabulary" type
> just in the sense that std::vector is a vocabulary type.
>
> With std::variant standardization the discussions often centered around two
> competing and valid views with different trade-offs. One view was that a
> variant should never be empty (like boost::variant). The other view was
> that it is okay for there to be an empty state and that it can lead to a
> simpler and more efficient implementation (which can be true, but leads to
> a type with more states/weaker invariants). In the standard we ended up
> with a compromise that had an empty state that we *sometimes* try to avoid,
> but that actually can have negative performance and binary size
> implications for some operations, but some operations like assignments can
> potentially be faster and the type can be smaller. That's just what the
> committee ended up with in the presence of people shouting from different
> sides, along with a fair share of misunderstandings of the basic exception
> guarantee. As long as the committee wants exactly one type, I suspect it
> won't be able to do anything drastically different in either direction.
> Peter's variant can live here as the fully realized never-empty variant,
> and there can hypothetically be the opposing realization (i.e. something
> that goes to the other extreme and doesn't do anything to avoid the empty
> state ever, but has operations with strong preconditions -- I've even
> started implemented one even though I'm more fond of never-empty variants
>
> https://github.com/mattcalabrese/argot/blob/master/include/argot/discriminated_union.hpp
> ).
>
> 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?

Regards,
&rzej;