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

Subject: Re: [boost] Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements)
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-04-05 17:38:41

On 4/3/2015 5: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:
>>
>>> 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.