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

Subject: Re: [boost] Foundational vs non-foundational libraries (was: Re: Thoughts on Boost v2)
From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2014-05-21 08:30:21

On 21 May 2014 12:45, Niall Douglas wrote:
>
> 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

Did exception_ptr come from Boost?

It first appeared in Boost 1.36, nearly two years after Beman's first
WG21 proposal for exception propagation and 18 months after Peter's
exception_ptr proposal that was closer.

> regex
>
> ... and so on. What is very obviously missing is frameworks except
> where those were also duplicated in C11,

I'm not sure the absence/presence of anything in C11 had much
influence on C++11, remember C++0x was feature-complete many years
ago, but it took a long time to bake the final standard (even /losing/
features along the way).

> so for example if C11 gained
> threads which it did, C++ 11 gained Boost's thread implementation

With non-Boost additions (move semantics, the <chrono> library, futures).

> rather than say a more C11 like thread implementation.

The C11 thread implementation arrived far too late to have been any
use to C++0x and locking without RAII would never have been taken
seriously by the C++ community  :-)

So I'm not sure C11 is at all relevant to the discussion of what made
it into C++11.

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

There isn't going to be a TR2, let alone a TR3, instead there are
going to be several mostly-independent Technical Specification
documents.

> boost::optional

optional is already in the draft Library Fundamentals TS.

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

Unlikely given we already have std::type_index.

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

The whole point of a TS is to be experimental, the contents are even
in namespace std::experimental (that said, what Boost considers
experimental and what WG21 considers experimental is not the same
thing :-)

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

Again, there is no TR2, there is not going to be a TR2.

> 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

Very strongly agreed.

Those who want Boost to provide a bridge between C++03 and C++11
because they can't use C+11 should stick to "Legacy Boost" (whether
that's v1.x or some fork that goes into maintenance mode) and not hold
back interesting new development.