Re: [boost] [variant] Maintainer

Subject: Re: [boost] [variant] Maintainer
From: David Sankel (camior_at_[hidden])
Date: 2015-06-26 18:09:47

Hi Antony,

Thanks for stepping up to the plate for being a maintainer of variant. I,
and I'm sure many others as well, really appreciate your willingness to
take on maintenance!

On Fri, Jun 26, 2015 at 12:59 AM, Antony Polukhin <antoshkka_at_[hidden]>
wrote:

> 2015-06-26 9:10 GMT+03:00 Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]
> >:
>
> > I would suggest you to have two separated classes, one the existing one
> > and the other that can be used to experiment and move towards whatever
> the
> > experimental standard variant would become. Note that the proposal is
> > moving a lot and there is not yet enough consensus on its semantic.
> >
>
> This seems like an overkill in this particular case.
>
> There's an Eggs.Variant that matches proposal better. Totally rewriting
> Boost.Variant to be close to it seems wrong. Instead I'll focus on adding
> missing metaprogramming features (tuple_size, tuple_element) and improving
> free functions (get<Index>(variant), comparisons). Such changes do not
> require separate class.

I do want to echo Vicente's sentiment though. What you see in N4450 may be
nothing like what we get in the standard. Although there was agreement at
the Lenexa meeting, everything is being discussed still. We wouldn't want
to get into the unfortunate situation where Boost.Variant models an early
proposal that ended up being discarded. If that were the case,
Boost.Variant would still have to stick with the older proposal in order to
maintain backwards compatibility.

Also, I think you probably want to look at N4516 which is the latest
version of the proposal and was what was accepted by WG21's LEWG (
http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4516.pdf). But, like I
said, we seem to be back at the drawing board so I'd be against making any
changes to Boost.Variant based on papers at this point. Well, at least on
issues that are contentious (like get<index>).

-- David Sankel