Re: [boost] Thoughts on Boost v2

Subject: Re: [boost] Thoughts on Boost v2
From: John Maddock (boost.regex_at_[hidden])
Date: 2014-05-17 06:09:14

> For the purposes of clarity, I am not a member of Boost. I do not sit
> on any committees, and have no representation nor standing with the
> community apart from doing some admin for GSoC. I would say that my
> opinions on this are so extreme that no one agrees with me, and I
> expect my presentation at C++ Now tomorrow to not be popular.
>
> I have however been doing a lot of canvassing whilst here at C++ Now.
> The main problems with Boost which are causing its decline are these:
>
> 1. Boost isn't sexy any more. As one very highly respected world
> famous engineer put it - and I won't say who, and I apologise to him
> for stealing his words without attribution:
>
> "Boost used to be about all the stuff you really wanted in the
> standard. Now Boost looks like all the stuff that wasn't good enough
> to get into the standard"

Ouch.

> 2. Everyone recognises there are serious problems with process,
> everything from how you were treated Stephen when you tried cleaning
> out cruft and only really Dave supported you, right through to the
> fact that peer review simply doesn't work any more. The Boost
> community has become quite selfish in recent years, as you would
> expect from those with a vested interest in the status quo before
> evolution. And for the record, I have no problem with those vested
> interests keeping their existing Boost, but I personally want as far
> away from C++ 03 as soon as is possible.

There have always been problems with the process - in short nobody ever 
wants to do the dirty work - writing reviews, rewriting old code etc 
etc.  It has always been thus.

> 3. All the interesting new C++ 11 libraries you find around the
> internet have zero interest in trying to join Boost, with a very few
> honorable exceptions. That speaks volumes, to me at least.

If that's true it would be interesting to know why.

However the entry bar to Boost has always been a difficult one to 
negotiate.  Mostly that's a good thing, but clearly putting folks off 
from even getting to the starting line is the negative side effect.  It 
is and has always been a difficult balancing act.

> Which suggests to me a need for a new Boost which attempts to apply
> the benefits of hindsight to what we learned with Boost v1. Now, it
> is extremely clear from this conference there is little appetite for
> that, but I think later on this year we're going to have three C++11
> libraries in the queue, and if things have not very significantly
> progressed in any of the three items above, I think that time will be
> right time to fork. And here is what I think should be in a fork of
> Boost:
>
> 1. Minimum required compiler feature set will be VS2014's. No use of
> Boost STL permitted where the C++ 11 STL provides a feature.

Sigh.  So workarounds, even totally trivial ones are banned?

I don't see that as a good balance.

But don't misunderstand me: Boost was founded to provide a haven for 
bleeding edge, experimental coding.  We should still be that, and I hope 
we can look favourably on C++1y library submissions.  There is a caveat 
however: we have only tended to accept bleeding edge compiler requiring 
libraries where that genuinely adds something to the library.

> 2. cmake instead of Boost.Build.

Another sigh.

We've had one very large transition (SVN to git) in the last year that 
has already delayed the next release by many months.  I would be 
strongly against another large transition anytime soon.  I have nothing 
in particular for or against CMake - though I can certainly see the 
attraction of an externally-supported build tool.

I suspect we lost the best part of a year transitioning from cvs to svn, 
I expect neither a change from svn to git, nor Boost.Build to something 
else to be any less painful.  Nobodies fault, it's just the way that it is.

Plus I'm not sure that this is the most important change we need - the 
time would probably be better spent improving the testing 
infrastructure, making Boost (and testing) more modular etc etc.

> 3. Eliminate peer review in favour of a suite of automated libclang
> based AST analysers. Instead of persuading people to review
> libraries, persuade them to review and improve the AST analysers.

I'm sorry but that's rubbish: peer review is much less about code 
quality, than the interface design, documentation, testing, and the "is 
this useful" litmus test.

> 4. Mandatory cross platform per-commit CI with unit testing exceeding
> 95% coverage. We don't care what unit test library is used so long as
> it can output results Jenkins can understand.

A much more worthy goal than changing the build system.

> 5. Mandatory all green thread, memory, UB sanitisers and clean
> valgrind. All also tested per-commit.

Also a worthy goal.  Although I would just note that valgrind has it's 
own bugs: no long double support is a killer for the Math lib.

I also note that an interested test-runner could do this right now this 
minute, by running their tests under Valgrind - I forget the magic 
incantation but Boost.Build supports this.  In fact if you look at the 
Jamfile I wrote for the Pool lib, that has built in valgrind testing 
support.

Of course the tests would take a *very* long time to run.

> 6. Mandatory CI testing for exception safety. I am hoping a clang
> rewriter can basically patch all exception throws and have them
> randomly throw for testing.

Which exceptions?  Many are not random at all, they are thrown in a 
completely deterministic manner.  The Math lib tests rely on:

function(a, b);  // should never throw, if it does it's a bug
function(a, c);  // should always throw.

And yes, these are tested.

> 7. Per-library source distributions instead of a monolithic blob.
> This implies some dependency management, but cmake makes that much
> easier. It also means we can eliminate the release cycle because each
> library does its own release cycle, and the correct (i.e. tested)
> version of dependencies are included into each per-library source
> distro. This solves the version lock problem currently plaguing
> git-ised Boost, at the cost of pushing the version lock problem onto
> users [1]. BTW I want to see a soak test of the unit tests for 24
> hours be all green before a release.

OK, also a worthy goal, I'm not sure how much CMake really helps though.

> 4. To incentivise authors to maintain their libraries as the quality
> bar is improved - the automated scripts will start to drop library
> rankings as the quality is raised, thus dropping that library in the
> overall rankings. Rather more importantly, it provides a natural
> "deprecation" mechanism, something sorely lacking in my opinion from
> present Boost.

For sure we need a better way to deprecate old, no-long-maintained 
libraries.  I'll throw in 2 of my old things: TR1 and call_traits which 
should both be deprecated.  Pool should probably go as well, but I'm 
sure there are others.

In the short term, clearly marking their documentation as deprecated, 
and/or no longer listing/linking to them in the documentation index 
would be a good start.

In fact I see no great impediment to implementing that for the next release?

Regards, John.