Re: [boost] [Developing for Boost saves time]( was Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem)

Subject: Re: [boost] [Developing for Boost saves time]( was Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem)
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-04-05 13:27:42

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-queue-tardiness-was-Cleaning-out-the-Boost-review-queue-Review--tp4674046p4674156.html
Sent from the Boost - Dev mailing list archive at Nabble.com.