Boost logo

Boost :

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

> 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

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


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at