On 4/2/2015 2:17 PM, Gonzalo BG wrote:

I'll briefly chime in to state that I have been using Eric Niebler's tagged_variant for a couple of months now and am very happy with it, it comes with range-v3:

https://github.com/ericniebler/range-v3/blob/master/include/range/v3/utility...

(note: the utility folder of range-v3 is full of true gems)

FWIW, I consider it usable, but not fully baked. I'd like to respond to this: On 4/2/2015 11:06 AM, Niall Douglas wrote:

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.

Speaking strictly for myself here: the reason I haven't pushed to get my recent open source contributions into Boost is not because I consider my code of higher quality. If anything it's quite the opposite. Getting a library into Boost is so daunting and time-consuming that -- at least for the work I'm doing these days -- I just don't have the time. It pains me to say that. I don't have the time to produce Boost-quality documentation and to exhaustively test everything. Concepts are coming. It's not hard to see that the STL will need a ground-up rewrite. I needed to get on the Concepts train, and it was going to pull out of the station with or without me. It would take half a year to make range-v3 Boost-worthy. By that time, I'd have missed my chance to get ranges baked in from day 1. Maybe that speaks to Boost's review process, but it doesn't speak to the quality of Boost's code, which I consider very high. I realize that doing an end-run around Boost to get ranges in the standard is deflating for everybody who has worked to make Boost what it is. That includes me. FWIW, if someone were to volunteer to polish the docs and tests and run it through a review, I'd be overjoyed to see range-v3 in Boost. Ditto for Meta. -- Eric Niebler Boost.org http://www.boost.org

Eric Niebler-4 wrote

Speaking strictly for myself here: the reason I haven't pushed to get my recent open source contributions into Boost is not because I consider my code of higher quality. If anything it's quite the opposite. Getting a library into Boost is so daunting and time-consuming that -- at least for the work I'm doing these days -- I just don't have the time.

My view is that if developing for Boost is taking extra time, you're doing it wrong.

I don't have the time to produce Boost-quality documentation.

If producing Boost quality documentation is taking extra time, you're doing it wrong. I'm not being facetious here. I think that one can't really verify that his library is correctly conceived and design until he tries to document it. In our world that means as clearly specified set of type requirements along with any other pre-conditions. The problem is that if you leave this until you're done, you discover that you've wasted a huge amount of time developing something that you don't really use - or could have been simpler.

and to exhaustively test everything.

If you're not writing the test as soon as you write a component how do you debug it? - or if your code doesn't need debugging (because its Eric Niebler I'm addressing here) How is anyone else sure it doesn't need debugging? You can't really progress without a test. So my suggestion is: a) start coding b) discover that something like "another variant type" is needed c) code "another variant type" d) code a test ofr "another variant type" e) debug at least part of it f) make the documentation for it - refine the type requirements g) go back and clean up the code and rerun the tests h) by this time you should have boost build or make scripts in order to test the damn thing. i) submit it to the boost incubator and see if anyone else can find complaints with "another variant type". This get's to free testers, comments, corrections and critiques. So far - you haven't done anything you won't have to do pretty soon anyway - an now you've got some free outsourcing j) pick he next piece and loop back to b) The only thing missing is the Boost Review process. It's hugely time consuming. It's useful - but not strictly necessary. What IS necessary to get your library considered for the standard is a concrete implementation with real world experience. All of the above steps are un-avoidable. So just submit it to the incubator and move on. If Boost want's to review it - great. If not - you'll still get most of the benefits. If you look at the library Safe Numerics in the incubator it has ONE review. For whatever reason, the author of that review put in some real effort. On the basis of his review I made a lot of small changes which will make a huge improvement in the safe numerics library. I don't really need Boost, I need the help and infrastructure that Boost members provide. They are not quite the same thing. I've skipped over one critical piece here. That is picking the right tools. Picking the wrong tools can consume a huge amount of time which doesn't contribute to the project. I spent a lot of time evaluating options for development tools and made my recommendations in the "Simple Tools" section of the incubator. The set I use and recommend aren't for everyone - but they do work well for me. Documentation in particular boils down to following a template for requirements and pre-conditions. Naturally Tutorial and Introduction can be added later. [note - off topic detour]

Concepts are coming.

dream on. The current versions looks to be captured in the "concepts lite" paper which is quite ill-conceived in my view. I have a huge problem with what I presume to be the canonical example they've chose "sortable". I talked about that at CPPCon. But besides that, we've had a simpler and "good enough" implementation of type requirements checking in the Boost Concept Checking library for over ten years - and hardly anyone uses it. A more elaborate version of something that isn't used is going to be used even less - not likely a success in my book. But then we never take any kind of poll about which features/libraries are actually used by C++ programmers. So we don't really have any idea what's really successful. This is perhaps a good thing. [end detour]

I needed to get on the Concepts train, and it was going to pull out of the station with or without me.

LOL - no way - it's guys like who are actually driving the train!

It would take half a year to make range-v3 Boost-worthy. By that time, I'd have missed my chance to get ranges baked in from day 1.

at the risk of repeating myself, you won't save any time by trying to shortcut the process.

Maybe that speaks to Boost's review process,

Factor the Boost review process out of the discussion. Make a boost quality library and let the Review process take care of itself. The main motivation for getting a library reviewed and accepted by boost is to get a certification of one's competence and accomplishment. You don't need any more of this from Boost. It wouldn't hurt, but you don't need it like the rest of us.

but it doesn't speak to the quality of Boost's code, which I consider very high.

It's variable. Considering the whole library - not just the code - In many case it needs to be higher - a lot higher.

I realize that doing an end-run around Boost to get ranges in the standard is deflating for everybody who has worked to make Boost what it is. That includes me.

I understand why people would look at it this way. And I think they're drawing on the wrong lesson. By skipping the Boost Review process, you're making a rational decision under the circumstances. It's a sign that boost has to evolve to stay current and relevant. How it has to evolve is something under active discussion. To me it's not deflating - it's inspiring!

FWIW, if someone were to volunteer to polish the docs and tests and run it through a review, I'd be overjoyed to see range-v3 in Boost. Ditto for Meta.

well finish them off and submit them to the incubator. Meta in particular would be interesting for a few reasons a) looks like you have it mostly done b) it's small interesting component of current interest - C++11+ and MPL replacement discussion c) it would let you demonstrate/test and lend credibility to the incubator d) it's the most likely way you might get someone to take over this part of the project - see free outsourcing above. e) Under "suggestions for libraries" there are two suggestions. Seems that Meta would fit in typlists - which I would prefer as library name as it dovetails better with A's book(s). I would like a separate smaller library for metafunctions - but I'm not sure if you've got that factored out or not. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Another-variant-type-was-peer-review-queu... Sent from the Boost - Dev mailing list archive at Nabble.com.

Despite what you think, concepts are real and they're coming. If you dislike the Concepts Lite approach, you're not alone, but that's what we're getting. It's certainly not all that C++0x concepts were, but there's some good things about that, and having built a non-trivial concepts-based library

The advantages language-based concepts provide are multi-phase checking and concept mapping, two features that concepts lite currently does not provide. Multi-phase checking could be added in the future, but concept mapping is somewhat complicated with concepts lite's current design.

(range-v3 uses a Concepts Lite emulation layer), it's really not bad. Range-v3 would be impossible without something like concepts, and real language support will help immensely, IMO.

I don't think you can compare library-based concepts to concepts lite. Library-based concepts(such as in ranges-v3) is a very natural and evolutionary step forward for concept checking. However, concepts lite has many surprises(and workarounds), in addition to the complications for future features of the language(such as concept mapping or type erasure), which stems from its core design of subsuming and propositional logic. We do need a language feature for concepts, but concepts lite is not it. I, as a library writer, will probably continue to use library-based concepts with a concepts lite C++ since it provides better composability and less surprises(even if it requires some macros).

Maybe that's because it has usability problems, and doesn't actually solve the problems concepts are intended to solve. You can't do concepts-based overloading with Boost.Concepts, for instance. Boost.Concepts gives only hard errors.

Exactly. One of the goals of concepts is to produce less error output, which Boost.ConceptCheck does not achieve. Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Another-variant-type-was-peer-review-queu... Sent from the Boost - Dev mailing list archive at Nabble.com.

Eric Niebler-4 wrote

I completely agree. And I have been documenting it. I have on my machine a 170 page proposal that I intend to submit for the next committee meeting. It exhaustively documents a not insignificant fraction of range-v3. It represents about 6 months of work. Trouble is, it is about as usable as documentation as any other part of the C++ standard. Which is to say: not at all.

Writing Boost documentation would be a whole other 6 months. You see choice I had to make.

I see this. But I would have hoped that the Boost and the proposal would contain much of the same information - though perhaps formatted differently.

Despite what you think, concepts are real and they're coming ..snip

...

I talked about that at CPPCon. But besides that, we've had a simpler and "good enough" implementation of type requirements checking in the Boost Concept Checking library for over ten years - and hardly anyone uses it.

Maybe that's because it has usability problems, and doesn't actually solve the problems concepts are intended to solve. You can't do concepts-based overloading with Boost.Concepts, for instance. Boost.Concepts gives only hard errors.

The main value in concepts is checking type requirements. The fact is a) this is easily done with Boost.Concepts b) few do it c) few even use concepts in their documentation. Without doing this they aren't going to be used in the code. Overloading based on concepts? I'm pretty skeptical given the above and the additional complexity and opaqueness this has the potential to add to C++.

Predicting is hard, especially about the future.

LOL - I won't disagree with that!

The Concepts TS happened completely without me. Concepts TS 2 -- the concept-infication of the STL -- was already being talked about. If it seems like I'm driving the train now, it's only because I talked a good game. :-)

I can see that. But I'm guessing there are a couple of other things in the mix which have potential to create disruption: a) Transactional memory - looks to me this is also driven by a small group of well connected fans. It also looks to that for this would motivated another pass at STL so that STL algorithms could be properly support this feature. b) Someone is going to start agitating for integration of constexpr through out the STL. That is, if they haven't already. Less disruptive - but still ...

...

...

but it doesn't speak to the quality of Boost's code, which I consider very high.

It's variable. Considering the whole library - not just the code - In many case it needs to be higher - a lot higher.

There's parts of Boost *I* would design differently. But that's not a quality judgement.

I'm not so much concerned about design issues which I think the boost "process" addresses pretty well. I'm much more concerned about usability issues. Implementation, documentation, deployment, dependencies, build etc. I believe that it's the bread and butter grunt work that everyone takes for granted that holds us back. In large part this is because it's importance is under appreciated and I'm trying to change that.

Meta is both typelists and metafunctions[^1]. They were separate, but that didn't buy anything so I put them together.

I agree that Meta would be a good thing to throw up on the incubator, and even to run through the Boost review process. It's a slightly different approach to metaprogramming, and I would need the feedback and usage before I could take it to the committee. (Range-v3 was different since it's similar in principle to Boost.Range.) Unfortunately range has eaten up all my time and probably will for a while.

[^1]: Meta doesn't have metafunctions per se. In Meta they're template aliases and alias classes.

It sounds like a very good thing for the incubator. Not so much as getting a boost review but for the fact the future of MPL, it's maintainence, it enhancement, replacement, etc. etc. has been much in discussion lately and it would be helpful to have all the projects related to this in the incubator so they can more easily be compared and contrasted. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Another-variant-type-was-peer-review-queu... Sent from the Boost - Dev mailing list archive at Nabble.com.

It doesn't even come close to fully improving template error messages in the way the C++0x concepts could

In what areas is Concepts Lite lacking in error reporting? Are you referring to the lack of multi-phase checking in Concepts Lite? Because it is possible to have multi-phase checking in the future, and I believe it is on the roadmap to be added.

The entire taxonomy of standard concepts for C++0x was done and the entire standard library was updated for it in N2914. It STILL got cut.

Well, I think one issue that always gets brought up is the number of concepts necessary in C++0x. Concepts Lite is taking the approach of having larger defined concepts, rather than defining smaller more modular based concepts. Either approach could be taken with C++0x concepts, and I don't think it points to an inherit design flaw with C++0x concepts.

It's a flawed design

The core part of its design is built around propositional logic and subsuming. While its an interesting idea, taking this design approach prevents future features such as specialization and concept mapping, which are vital for generic programming. The idea of creating a fork for concept-based libraries would just lead to similar problems with the python 3 fork. Plus, it comes with other surprises(like not being able to use type traits in the requires clause).

it would be a mistake for it to be in the standard.

Especially, since the current tools are improving in regards to error reporting(even when using the current template constraints) that the need for Concepts Lite becomes less. This would further hinder adoption even if it were in the standard. Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Another-variant-type-was-peer-review-queu... Sent from the Boost - Dev mailing list archive at Nabble.com.

FYI, the eggs.variant discussed above also uses a recursive union, e.g. see: https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/detail/...

On Sat, Apr 4, 2015 at 3:06 PM, Matt Calabrese wrote:

You need to use a recursive union if you are to get some constexpr support.

Well, let me rephrase, you can expand it out by preprocessor to a certain limit and get that too, but you can't just use aligned storage. At some point you need to hit a recursive case. -- -Matt Calabrese

AMDG On 04/04/2015 04:33 PM, Larry Evans wrote:

On 04/04/2015 05:08 PM, Matt Calabrese wrote:

...

On Sat, Apr 4, 2015 at 3:06 PM, Matt Calabrese wrote:

...

You need to use a recursive union if you are to get some constexpr support.

Well, let me rephrase, you can expand it out by preprocessor to a certain limit and get that too, but you can't just use aligned storage. At some point you need to hit a recursive case.

Could you please elaborate on why recursion cannot be avoided?

Variadic parameter packs can't be expanded on class (or in this case union) members. template union variant_storage { T t;... // illegal }; In Christ, Steven Watanabe

AMDG On 04/04/2015 05:07 PM, Larry Evans wrote:

Matt said aligned storage can't be used; hence, I assume he meant that the required alignment for the aligned storage would require recursion, but that would be constexpr template *function* recursion not template struct or union recursion.

This doesn't make any sense to me. The reason that aligned storage doesn't work has nothing to do with calculating the alignment.

Hence, I suppose Matt meant the recursion requirement was for functions not commposites (e.g. struct or union).

In Christ, Steven Watanabe

AMDG On 04/04/2015 05:20 PM, Larry Evans wrote:

On 04/04/2015 06:18 PM, Steven Watanabe wrote:

...

The reason that aligned storage doesn't work has nothing to do with calculating the alignment.

Why does using aligned_storage not work, please?

On 04/04/2015 04:06 PM, Matt Calabrese wrote:

You need to use a recursive union if you are to get some constexpr support.

In Christ, Steven Watanabe

On 4/4/2015 4:42 PM, Larry Evans wrote:

On 04/04/2015 06:25 PM, Steven Watanabe wrote:

...

AMDG

On 04/04/2015 05:20 PM, Larry Evans wrote:

...

On 04/04/2015 06:18 PM, Steven Watanabe wrote:

...

The reason that aligned storage doesn't work has nothing to do with calculating the alignment.

Why does using aligned_storage not work, please?

On 04/04/2015 04:06 PM, Matt Calabrese wrote:

...

You need to use a recursive union if you are to get some constexpr support.

OK. So Matt, could you please elaborate on why constexpr support requires a recursive union?

To put an object into aligned storage requires placement new, which is not constexpr. Using a recursive union avoids the need for placement new. -- Eric Niebler Boost.org http://www.boost.org

On Mon, Apr 6, 2015 at 2:53 PM, Matt Calabrese wrote:

Precisely this. Unfortunately, even with the recursive variant, you are still very limited in what you can do with a constexpr variant.

Woops, meant to say "recursive union" and not "recursive variant." -- -Matt Calabrese

On Wed, Apr 8, 2015 at 6:14 AM, Larry Evans wrote:

I can see how a new expression which is not a placement new would be disallowed; however, I don't see a reason why placement new would be disallowed when the void* 2nd argument is a pointer to a constexpr aligned_union member variable. Could you please provide a reference or explanation of why placement new is not allowed in a constexpr?

+1 Regardless of how it is achieved, there should really be some way of getting this functionality with a literal type. Even with a recursive union implementation, users are heavily limited in terms of what they can do. For instance, copying/moving the variant (at least in the general case) cannot be accomplished in the language with constexpr currently, at least as far as I'm aware. In other words, you sadly cannot even return one from a function in the constexpr world. It's unfortunate because there is nothing that logically prohibits such a type from being much more capable at compile-time, and the ramifications could be pretty powerful. IIRC, Eric's work uses a discriminated union behind the scenes for some ranges (joined ranges and probably others?). Being able to make a discriminated union that is a regular type could therefore make it much more feasible to work with high order functions that operate on ranges at compile-time, including complicated transformed and composite ranges. With such facilities, and if Faisal's constexpr lambda efforts eventually make it into the language, compile-time programs could potentially get significantly more powerful and easier to write. More of the STL range algorithms and literal types of the future could have implementations that are shared between the run-time and compile-time world. -- -Matt Calabrese

On Apr 9, 2015 2:57 PM, "pfultz2" wrote:

Why can't you create a constexpr copy constructor with a recursive union?

You can't in the general case because you have to call the constructor of the appropriate internal type. You can't placement new, so you have to do it via a member initializer, so which internal type's constructor do you call? If you have all types with trivial copy constructors you can make it work, but not in the general case.

On 04/08/2015 08:14 AM, Larry Evans wrote:

On 04/04/2015 07:55 PM, Eric Niebler wrote:

...

On 4/4/2015 4:42 PM, Larry Evans wrote:

...

On 04/04/2015 06:25 PM, Steven Watanabe wrote:

...

AMDG

On 04/04/2015 05:20 PM, Larry Evans wrote:

...

On 04/04/2015 06:18 PM, Steven Watanabe wrote:

...

The reason that aligned storage doesn't work has nothing to do with calculating the alignment.

Why does using aligned_storage not work, please?

On 04/04/2015 04:06 PM, Matt Calabrese wrote:

...

You need to use a recursive union if you are to get some constexpr support.

OK. So Matt, could you please elaborate on why constexpr support requires a recursive union?

To put an object into aligned storage requires placement new, which is not constexpr. Using a recursive union avoids the need for placement new.

Thanks Eric.

I see the restriction about new expression here:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html

I can see how a new expression which is not a placement new would be disallowed; however, I don't see a reason why placement new would be disallowed when the void* 2nd argument is a pointer to a constexpr aligned_union member variable. Could you please provide a reference or explanation of why placement new is not allowed in a constexpr?

It's not just the new expression limitation. The static_cast from void const* is not allowed either, and that's also required, AFAICT, in the aligned_union implementation of variant. Attached is code which illustrates both limitations. #define USE_PLACEMENT_NEW to show the 1st limitation. #define USE_STATIC_CAST_VOID to show the 2nd limitation. The code was compiled with clang 3.5. -regards, Larry

On 4/13/2015 1:48 PM, Larry Evans wrote:

Thanks again, Eric.

However, the range-v3 variant get member function here:

https://github.com/ericniebler/range-v3/blob/master/include/range/v3/utility...

is not a constexpr function, so why isn't std::aligned_union for the data storage and a bunch of placement news for construction, and reinterpret casts for the get member function used instead of the recursive union, located here:

https://github.com/ericniebler/range-v3/blob/master/include/range/v3/utility...

?

I've been busy. -- Eric Niebler Boost.org http://www.boost.org

On 4/4/2015 9:31 PM, Larry Evans wrote:

On 04/04/2015 05:49 PM, Steven Watanabe wrote:

...

AMDG

On 04/04/2015 04:33 PM, Larry Evans wrote:

...

On 04/04/2015 05:08 PM, Matt Calabrese wrote:

...

On Sat, Apr 4, 2015 at 3:06 PM, Matt Calabrese wrote:

...

You need to use a recursive union if you are to get some constexpr support.

Well, let me rephrase, you can expand it out by preprocessor to a certain limit and get that too, but you can't just use aligned storage. At some point you need to hit a recursive case.

Could you please elaborate on why recursion cannot be avoided?

Variadic parameter packs can't be expanded on class (or in this case union) members.

template union variant_storage { T t;... // illegal };

Why not:

template struct variant_storage : std::aligned_union < 0 //Let aligned_union decide the size needed. , char //handle case where size_of...(T) == 0. , T... > { };

This provides the storage needed. No constexpr functions yet. The egg code mentioned by gonzalobg88@gmail.com:

https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/detail/...

had several constexpr( or at least EGGS_CXX11_CONSTEXPR) functions. Are one of those requiring a recursive union for implementation?

Yes, pretty much all of them require a recursive union for constexpr support. The details can be found here http://talesofcpp.fusionfenix.com/post-20/eggs.variant---part-ii-the-constex... and here https://akrzemi1.wordpress.com/2012/12/13/constexpr-unions/ Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

On 2 Apr 2015 at 21:17, Vinícius dos Santos Oliveira wrote:

...

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

The only troubles I got trying to write a Boost-like libraries is the excessive NIH syndrome. Tools like btool and quickdoc, which are a pain to use and are no better than the competitors. If these tools were designed without the assumption that you have a Boost tree lying around just to use them, the barrier would be lower.

It's looking like the upcoming crop of new Boost libraries are all not requiring Boost, so I think you're going to get what you want. Most are header only too. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 4/2/2015 3:06 PM, Niall Douglas wrote:

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

Eggs.Variant started as an experiment on what a generalized union would look like. It tries to be to `union` what `std::tuple` is to `struct` (it is not a sum type like Boost.Variant). I based the design on `std::experimental::optional`, and I'm already regretting those places where I didn't. I wouldn't consider submitting it for inclusion into Boost as that would force me to stabilize things, which would conflict with my desire to experiment. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

On 4/3/2015 4: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 should not bother you. Boost should encourage programmers to write a library using the C++11 or C++14 standard if the domain of the library requires such use. It is always nice to have a library work with C++98 compilers but nothing should stand in the way of Boost libraries requiring C++11/C++14 compilers.

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

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.