Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements)
On 2 April 2015 at 08:13, Niall Douglas <s_sourceforge@nedprod.com> 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." -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
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/
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)
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
On 2 Apr 2015 at 17:33, Eric Niebler wrote:
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.
I absolutely agree. I'm just out of six weeks of staying up till 5am each night after the family went to bed to get AFIO v1.3 out the door. That's because it had to be Boost peer review quality as it's in the review queue. I ended up dumping perhaps 200 hours in getting a feature complete and what I would have called "finished" library into a Boost peer review quality library. That's 200 hours I did not bill hourly to clients for, and as a consequence my earnings have taken a big hit for the past two months. If I were still working at BlackBerry, I am highly unsure if regularly releasing a Boost library is compatible with not getting divorced and/or not fired.
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.
And this is where the nub lies in where my vision of Boost 2.0 differs from Robert's. I want to see an incrementing score automatically generated such that when you Eric throw caution to the wind and accidentally dump three days of work into your potential Boost library because something in it bugged you, you immediately see a jump in your library's rank. If Boost programmers are like any other type of human being, that immediate gratification has highly positive effects on you repeating that misallocation of your time sooner rather than later. Especially as most of the 200 hours invested in getting a library release Boost ready is drudge work - soak unit testing for 24h, writing yet more unit testing, spending three nights consecutively in the debugger tracking down some rare unrepeatable segfault, writing yet more tutorial toy use examples. That sort of thing. All stuff which needs to be rapidly rewarded psychologically, else you'll avoid it even more. That tight feedback loop spurring people on psychologically to accidentally do better can't happen when human review is involved. Especially when people are waiting *three* *years* to get a review - though I am very glad Emil finally has a review manager as a result of this thread. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
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.
On 4/3/2015 4:15 PM, Robert Ramey wrote:
Eric Niebler-4 wrote
Eric Niebler-4? What happened to the first 3 Eric Nieblers?
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.
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.
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.
I was selling range-v3 short. It *does* have fairly extensive tests. I was able to crib much of them from libc++. <snip>
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".
The "canonical example" they chose is the STL. See here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf 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 (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 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.
A more elaborate version of something that isn't used is going to be used even less - not likely a success in my book.
<shrug> Predicting is hard, especially about the future.
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!
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. :-)
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.
I won't repeat myself.
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.
Thank you.
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 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
Few docs. Few tests. The only reason it exists as a thing at all is because Gonzalo factored it out of range-v3 and made a repo for it.
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.
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. -- Eric Niebler Boost.org http://www.boost.org
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.
pfultz2 wrote
Exactly. One of the goals of concepts is to produce less error output, which Boost.ConceptCheck does not achieve.
I would dispute that. Boost.ConceptCheck doesn't produce minimal output error listing, but it produces a lot less than when no concept checking is being used. And it does point to the parameter and type constraints which conflict. So it's better than nothing and not hard to use. But agree that Boost.ConceptCheck is not without problems - it was written over 12 years ago!!!. I'm sure it could be improved with C++11+ and of course I realize that you've submitted a library to do just that! I haven't gotten around to studying it yet - but I am interested. 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.
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.
On Sat, Apr 4, 2015 at 4:36 PM, Eric Niebler <eniebler@boost.org> wrote:
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.
Late on the reply here, but I just noticed the thread. You know my stance (I am very much against concepts lite). You've stated this many times, but I will reiterate that I would definitely not assume that Concepts Lite is what we're getting. It's yet to be a part of the language and I personally have seen more as opposed to fewer people opposing it as time goes on. There is a mantra of "this is definitely what we're getting in the standard whether you like it or not" that's been spouted by many people involved with or making use of concept-lite, but it's a horribly premature assessment. Just for some perspective: C++0x concepts made it way further along in standardization than where we are with Concepts-Lite right now. 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. Concepts-lite might not even make it that far due to growing skepticism. It doesn't even come close to fully improving template error messages in the way the C++0x concepts could and its current design entirely precludes us from ever getting there, short of deprecating concepts lite at some point in the future. It's a flawed design and it would be a mistake for it to be in the standard.
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.
On 04/02/2015 07:33 PM, Eric Niebler wrote:
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.
Hi Eric. The code at: https://github.com/ericniebler/range-v3/blob/master/include/range/v3/utility... shows variant_data<T,Ts...> is defined recursively. Wouldn't this cause large compile times? The reason I say this is because, IIRC, one of the reasons for the some of the preprocessor use in the current mpl is to reduce compile times by "chunking" a number of the T's into a single component in the recursive inheritance chain. IIRC, the chunk size in mpl was 10. Have you seen any compile time problems with this recursive variant_data? -regards, Larry
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/...
You need to use a recursive union if you are to get some constexpr support. On Sat, Apr 4, 2015 at 8:15 AM, Gonzalo BG <gonzalobg88@gmail.com> wrote:
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/...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- -Matt Calabrese
On Sat, Apr 4, 2015 at 3:06 PM, Matt Calabrese <rivorus@gmail.com> 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
On 04/04/2015 05:08 PM, Matt Calabrese wrote:
On Sat, Apr 4, 2015 at 3:06 PM, Matt Calabrese <rivorus@gmail.com> 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?
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 <rivorus@gmail.com> 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<class... T> union variant_storage { T t;... // illegal }; In Christ, Steven Watanabe
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 <rivorus@gmail.com> 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<class... T> union variant_storage { T t;... // illegal };
In Christ, Steven Watanabe
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. Hence, I suppose Matt meant the recursion requirement was for functions not commposites (e.g. struct or union). Matt?
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
On 04/04/2015 06:18 PM, Steven Watanabe wrote:
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.
Why does using aligned_storage not work, please?
Hence, I suppose Matt meant the recursion requirement was for functions not commposites (e.g. struct or union).
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 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? -regards, Larry
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
Sorry for the delayed response! On Sat, Apr 4, 2015 at 5:55 PM, Eric Niebler <eniebler@boost.org> wrote:
To put an object into aligned storage requires placement new, which is not constexpr. Using a recursive union avoids the need for placement new.
Precisely this. Unfortunately, even with the recursive variant, you are still very limited in what you can do with a constexpr variant. -- -Matt Calabrese
On Mon, Apr 6, 2015 at 2:53 PM, Matt Calabrese <rivorus@gmail.com> 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 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? -regards, Larry
On Wed, Apr 8, 2015 at 6:14 AM, Larry Evans <cppljevans@suddenlink.net> 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
For instance, copying/moving the variant (at least in the general case) cannot be accomplished in the language with constexpr currently
Why can't you create a constexpr copy constructor with a recursive union? 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.
On Apr 9, 2015 2:57 PM, "pfultz2" <pfultz2@yahoo.com> 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.
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?
I see. You have to decide the member initialization based on a runtime value. Thats just not possible. However, the more I think about it, I don't think a constexpr union type makes much sense. The type is known at compile-time. Instead a constexpr sum type would just store the type and the possible types: template<class T, class... Choices> class constexpr_sum_type : T { ... }; Then the `Choices...` types can be used in the visitor to enforce compile time checking of all the branches. Perhaps, some generalized unpacking mechanism could help normalize the usage of constexpr and non-constexpr sum types. 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.
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 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 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<Ts...> 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... ? -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<Ts...> 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 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 <rivorus@gmail.com> 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<class... T> union variant_storage { T t;... // illegal };
Why not: template<class... T> 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? -regards, Larry
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 <rivorus@gmail.com> 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<class... T> union variant_storage { T t;... // illegal };
Why not:
template<class... T> 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
2015-04-02 15:06 GMT-03:00 Niall Douglas <s_sourceforge@nedprod.com>:
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. But that's just my opinion. Better collect the opinion from current Boost authors. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker
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 April 2, 2015 8:17:48 PM EDT, "Vinícius dos Santos Oliveira" <vini.ipsmaker@gmail.com> wrote:
2015-04-02 15:06 GMT-03:00 Niall Douglas <s_sourceforge@nedprod.com>:
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.
Those tools were created long before there were true competitors. Whether there are viable alternatives now is not really the issue. To switch to something new requires proving that the new tool does what the old one does and that it improves on the old tool significantly. Otherwise, there's no incentive to switch. ___ Rob (Sent from my portable computation engine)
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
2015-04-02 18:38 GMT+03:00 Nevin Liber <nevin@eviloverlord.com>:
On 2 April 2015 at 08:13, Niall Douglas <s_sourceforge@nedprod.com> 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) * egg.variant has some doubtfull places (all the comparisons of variant with T, by index inplace constructors). This will be probably fixed during review! -- Best regards, Antony Polukhin
On 4/3/2015 4:33 PM, Antony Polukhin wrote:
2015-04-02 18:38 GMT+03:00 Nevin Liber <nevin@eviloverlord.com>:
On 2 April 2015 at 08:13, Niall Douglas <s_sourceforge@nedprod.com> 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 April 3, 2015 6:32:48 PM EDT, Edward Diener <eldiener@tropicsoft.com> wrote:
On 4/3/2015 4:33 PM, Antony Polukhin wrote:
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.
Boost does not try "to stick to C++98". If there's no hardship, we encourage _continued_ C++98/03 compatibility, but new libraries need not consider the older language. ___ Rob (Sent from my portable computation engine)
On 4/3/2015 5:33 PM, Antony Polukhin wrote:
2015-04-02 18:38 GMT+03:00 Nevin Liber <nevin@eviloverlord.com>:
On 2 April 2015 at 08:13, Niall Douglas <s_sourceforge@nedprod.com> 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.
participants (14)
-
Agustín K-ballo Bergé -
Antony Polukhin -
Edward Diener -
Eric Niebler -
Gonzalo BG -
Larry Evans -
Matt Calabrese -
Nevin Liber -
Niall Douglas -
pfultz2 -
Rob Stewart -
Robert Ramey -
Steven Watanabe -
Vinícius dos Santos Oliveira