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

Subject: Re: [boost] Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-04-02 14:06:15

On 2 Apr 2015 at 10:38, Nevin Liber 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?

I don't think any such request has emerged. I base my understanding 
on the fact eggs.variant is written by an old timer Booster, yet as 
is obvious from the source code it is not intended to enter Boost.

Why its author does not intend this, or if I am wrong in my 
understanding from examining the source code, I'd imagine its author 
is the right person to ask. I am merely inferring from a detailed 
examination of its source code (I helped get VS2013 support in 
there).

> 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".

eggs.variant is pleasant to use. Boost.Variant is not.

eggs.variant makes full use of C++ 11 and constexpr's into zero 
overhead where possible. Boost.Variant does not.

eggs.variant is implemented by a true master of the language, and it 
shows throughout. It's very well designed and thought through, so 
stuff like map keying just works naturally as does a ton of other C++ 
idioms. I haven't studied Boost.Variant's implementation enough to 
say one way or another, but it has never struck me personally as 
being as well designed and thought through. It is of course over a 
decade old, and was written when C++ 98 conforming compilers were 
just arriving.

Just constexpr support alone makes for a whole new class of variant 
implementation.

> 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."

These endless discussions about how best to implement Boost's future 
wouldn't be happening if every top tier new C++ library was always 
assumed de facto by its author to eventually be destined for Boost. 
The fact that so many top tier authors, including so many formerly 
with a big presence here, no longer bother with Boost I think speaks 
volumes about what's gone wrong here with how library quality is 
assessed here.

I think Boost needs to very substantially increase the value add on 
offer to library authors over what is on offer at present.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/