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/