[boost] Foundational vs non-foundational libraries (was: Re: Thoughts on Boost v2)

Subject: [boost] Foundational vs non-foundational libraries (was: Re: Thoughts on Boost v2)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-05-21 07:45:40

On 20 May 2014 at 1:17, Jonathan Wakely wrote:

> >> "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"
> >
> > I disagree with it completely and fighting the urge to use the word
> > "ridiculous". There are no tools like Boost.Intrusive, Boost.Spirit,
> > Boost.Interprocess or Boost.ASIO, not to mention things like XML, advanced
> > networking (HTTP, FTP, SSL, etc.), encryption, the holy grail of GUI and many
> > other domains not covered by Boost. You got threading, regex and a couple new
> > containers and think you're covered? I think the previously hopelessly lacking
> > STL got a little less hopelessly lacking.
> 
> I didn't read that quote as saying that the standard library has
> everything you want, only that the things you want aren't in Boost
> either.

I think that was exactly the sentiment of the original speaker. For 
example, everyone recognises that something ASIO-like ought to enter 
the standard, it just isn't present ASIO.

> Maybe XML, advanced networking, encryption and GUI libraries are "the
> stuff you really want in the standard" but you won't find them in
> Boost.

Which neatly brings me onto reporting on the discussions at C++ Now 
after I made the OP on Friday.

In thinking through on why Boost may be dying in a C++ 11 world, 
someone raised a very interesting point on foundational vs 
non-foundational libraries. If you look at all the stuff which made 
it from Boost into the C++ 11 standard (and excluding anything also 
entering C11), as a rule of thumb it was all foundational e.g.

shared_ptr
exception_ptr
regex

... and so on. What is very obviously missing is frameworks except 
where those were also duplicated in C11, so for example if C11 gained 
threads which it did, C++ 11 gained Boost's thread implementation 
rather than say a more C11 like thread implementation.

I personally found this pattern to be highly useful. It suggests to 
us what added to recent Boost will enter C++ 17 or TR3, so taking a 
guess:

boost::optional
boost::expected

... are very highly likely candidates, as are any of the 
single-purpose Boost libraries such as Boost.TypeIndex.

What is of course very interesting here is that by their nature, 
foundational libraries have a strong low hanging fruit nature, so the 
number of new additions is going to exponentially decrease over time. 
For example, I can see a very conservative C++11/14 based MPL having 
some chance for a TR3, but a Boost.Hana as presently proposed would 
probably be deferred till the next major release after TR3 as it is 
too experimental.

Rather harder is to predict what might happen to a conservative 
generic monadic continuations framework based on expected<> et al. If 
done right, that would provide a base framework for all async in C++, 
thus allowing futures to mix seamlessly with ASIO and therefore async 
i/o with async anything else. That *could* become Boost's primary 
contribution to TR3, and finally provide a valid path for getting 
something ASIO-like into the standard (I am not hopeful than ASIO 
will be approved for TR2 personally, ASIO isn't stable enough, plus 
ASIO's current design does not seamlessly interop with other async in 
a generic way).

Bringing this back to the point of a Boost v2, if Boost defines 
itself as the staging ground for additions to the C++ standard - a 
highly valuable enterprise IMHO - then a C++ 11 only reboot of Boost 
into a new fresh collection of libraries is paramount (and once 
again, I stress that the 03 Boost isn't going anywhere, think of it 
like the Python 2.x vs 3.x split), especially as one can fix many 
problems like CI testing, build, distribution, dependencies and even 
directory layout (a big thing we really also need is formal 
organisation around C++ Modules, present Boost would need substantial 
refactoring, even more than the git translation).

I also still think that we can do a lot better with libraries in the 
review queue seeing as that list is likely to keep growing. Someone 
suggested that my earlier metric scoring proposal could be applied to 
those libraries in the queue with the top ranked in quality appearing 
in a separate category of "unreviewed" source distro, I think that a 
reasonable idea.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/