On Fri, Nov 27, 2020 at 12:56 PM Matt Borland via Boost < boost@lists.boost.org> wrote:
On Fri, 2020-11-27 at 11:58 +0300, Antony Polukhin via Boost wrote:
== The Solution TL;DR: we need a C++17 fork of Boost with close to 0 dependencies between libraries and namespace versioning.
If I may propose another course of action for discussion what about a Boost 2.0 that is based on the C++20 standard? One of the goals of modules was to reduce compile times/overhead especially with monolithic libraries like boost. After a module has been imported one time it should be nearly free to use thereafter. [...] We could use the python 2/3 model where both are supported with a published countdown to when new development ceases on the old version.
Hi. I like that idea. I'm on C++17 and Boost 1.74, likely for a long time*, so a C++17 Boost fork would work better for me, but C++20's modules and concepts do seem like a stronger base for a Boost 2.0 and would yield bigger bang for the buck, longer term. Boost 1.0 would remain, mostly as it is currently, with a wide range of supported standards and compilers. But a subset of Boost would be modularized and ported to C++20 and later, taking full advantage of that much higher footing. I also think Boost 2.0 should not try to work around buggy C++20 compilers (and std-lib), and simply accept that some advanced libraries won't work on non-conforming C++20 compilers. Kinda like Boost.Hana didn't try to work-around MSVC bugs of the past. Have Boost 2.0 look forward to the future, and the next 10/20 years while letting Boost 1.0 look back at the past 20 years (with still some maintenance for the near future). The analogy with Python2/3 is also a good one IMHO. This is just wishful thinking of course. Maintainers may not want to port to Boost 2.0 >= C++20 while still maintaining Boost 1.0. I just think Boost needs a second breath, and a clean reboot for the next decade. FWIW, --DD * Like many companies, we upgrade compilers and dependencies only every 2-3 years.