Subject: Re: [boost] Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements)
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-04-03 18:32:48
On 4/3/2015 4:33 PM, Antony Polukhin wrote:
> 2015-04-02 18:38 GMT+03:00 Nevin Liber <nevin_at_[hidden]>:
>> On 2 April 2015 at 08:13, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
>>> was recently working with eggs.variant for example, and that is Boost
>>> quality written to Boost guidelines and yet I understand there is
>>> zero interest in it entering Boost, despite it being superior to
>>> Boost.Variant in almost every way.
>> I don't remember anyone asking if they'd like to see this in Boost. Could
>> you point to a thread?
>> Even though you claim it is superior in almost every way, if I'm reading it
>> correctly it has one fundamental difference in that it models
>> "at-most-one-of" vs. Boost.Variant which models "exactly-one-of".
>> And yes, I would like to see it in Boost, because as variant gets proposed
>> for the standard, it would be better to have a lot more user experience to
>> help us decide that fundamental question.
>> That certainly fits the current mission in that "We aim to establish
>> 'existing practice' and provide reference implementations so that Boost
>> libraries are suitable for eventual standardization."
> I've been slowly improving Boost.Variant for two last years to achieve
> result close to egg.variant. It is good that egg.variant exist and I'd like
> to see it in Boost. Two things disturb me:
> * egg.variant it requires a modern C++11 compiler in C+11 mode (Boost tries
> to stick to C++98)
This should not bother you. Boost should encourage programmers to write
a library using the C++11 or C++14 standard if the domain of the library
requires such use. It is always nice to have a library work with C++98
compilers but nothing should stand in the way of Boost libraries
requiring C++11/C++14 compilers.
> * egg.variant has some doubtfull places (all the comparisons of variant
> with T, by index inplace constructors). This will be probably fixed during