Re: [boost] Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements)

On 4/3/2015 5:33 PM, Antony Polukhin wrote:

2015-04-02 18:38 GMT+03:00 Nevin Liber :

...

On 2 April 2015 at 08:13, Niall Douglas wrote:

...

I 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 is one of the reasons why people mistakenly discard submitting libraries for Boost review. There is no such requirement to "stick to C++98".

* egg.variant has some doubtfull places (all the comparisons of variant with T, by index inplace constructors). This will be probably fixed during review!

I agree that there are some not-so-nice points, but I don't think the two you mention are part of that set. The relational operators come straight from `std::optional`, where it was debated for a long time (long enough to push it out of C++14 and into a TS). The *optional* indexed inplace constructors are an absolute must for a generalized union, where more than one member can share the same type (note there's by type inplace constructors too when not ambiguous). Keep in mind that the two libraries model different abstractions (generalized union v. sum type), and that forcefully requires slightly different interfaces. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com PS: I guess by now this can be construed as off-topic, so feel free to contact me directly to continue any debate.