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

Subject: Re: [boost] [review][variant2] Variant2 Review Starts April 1
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2019-03-26 16:46:20

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.