Boost logo

Boost :

Subject: Re: [boost] [review][variant2] Variant2 Review Starts April 1
From: dariomt_at_[hidden]
Date: 2019-03-26 10:17:42


>
> On Mon, 25 Mar 2019 at 17:18, dariomt--- via Boost <boost_at_[hidden]>
> wrote:
>
> > ... as I would expect many more current users of the venerable
> > boost::variant than of its much younger cousin std::variant.
> >
>
> Why do you expect that and do you think that will stay that way?

Well, Boost.Variant has been around so much more time than std::variant, so
this seems obvious to me. For new code, maybe people will just use
std::variant, but there's more old code than new code.

Also, I'd say the cost of migrating from Boost.Variant to std::variant is
non-zero, and the benefits are not clear (to me), so I'd expect not many
people to undergo this migration.

My feeling is that the library is aimed at current users of std::variant,
offering a "better" pin-compatible alternative, but if I'm using
Boost.Variant I believe I also should be considered a potential user.

That's why I'm curious about the Boost.Variant2 review, we might get more
clarity by comparing the three versions, and we may even get guidance for a
migration path from Boost.Variant to Boost.Variant2.

> My
> personal feeling is that C++17-use is picking up at break-neck speed. For
> good or for worse, although there appears to be a lot of controversy over a
> (any) variant [and there are quite some quite different implementations
> around], the std::variant is the one in the std, which seems to give it a
> head start.

Well, in my (limited) experience Boost is ubiquitous, so being in std is
not that much of a head start.

> 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.
>
> degski
>

I wonder if code dealing explicitly with valueless_by_exception() will
break if you make this change.


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