Boost logo

Boost :

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: Eric Niebler (eniebler_at_[hidden])
Date: 2015-04-04 19:36:43

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


>> 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:

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 list run by bdawes at, gregod at, cpdaniel at, john at