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.