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
2015-06-26 9:10 GMT+03:00 Vicente J. Botet Escriba < vicente.botet@wanadoo.fr
:
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