The new Boost 17.0.0

From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2020-11-27 08:58:01

Hi,

== The problem.
TL;DR: we are having huge troubles with usability and popularity!

Quite a lot of companies forbid using Boost because:
* it provides vocabulary types, that should be the same across the
whole project (like shared_ptr, filesystem::path or optional).
Otherwise it's hard to combine different APIs
* it is huge, in consists of legacy on more than a half, with a lot of
dependencies between libraries. This is extremely painful for big
companies, because there's no efficient distributed build system. Each
company invents it's own and/or tries to minimize headers by all
means.

New companies (startups) also avoid Boost:
* "We are using C++17, we do not want legacy libraries with C++98 support"
* Junior developers are confused by multiple vocabulary types. "Should
we use boost::optional or std::optional?"
* hard to upgrade, because symbols are not versioned

ISO C++ WG21 community not willing to push prototypes into Boost. "We
aim to establish "existing practice" and provide reference
implementations so that Boost libraries are suitable for eventual
standardization." - that's not really true any more.

== The Solution
TL;DR: we need a C++17 fork of Boost with close to 0 dependencies
between libraries and namespace versioning.

С++17 provides many vocabulary types, feature test macro and a bunch
of features for variadic templates. All of that allows us to drop a
lot of weight and fix majority of popularity and usability problems.

Rule of a thumb should be: "If the C++17 provides that functionality -
use the standard version".

That approach would allow to loose a lot of weight, do not mess with
vocabulary types and significantly reduce dependencies
https://pdimov.github.io/boostdep-report/master/module-levels.html

By levels:
config 0 -> we probably would not need it any more
assert 1 -> 0
core 2 -> 1 (or 0 if we merge it with asser)
smart_ptr 4 -> 2
exception 5 -> 2
stacktrace 5 -> 2
intrusive 5 -> 2
outcome 6 -> 3
container 6 -> 3
gil 11 -> 2?
context 16 -> 2?
dll 17 -> 1
asio 18 -> 3?
beast 19 -> 4?

== The Path
TL;DR: we should start the Boost17 now and ship it as we are ready.
Old Boost should be still available.

The new approach requires quite a lot of effort and not all the
maintainers have enough time to do the migration. We should keep
releasing the existing Boost, while migrating the libraries to the
Boost17.

The migration is not as hard as it seems. It took 2 or 3 days to make
Boost.DLL work with either boost or std filesystem. It could be done
in less than a day, if I do not have to support the Boost filesystem.

== Action points
0) Discuss
1) Bury the idea, wait for a few years, goto 0); or make a boost17
repo with the same layout as the existing one, but without submodules
2) start the migration

-- 
Best regards,
Antony Polukhin