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.