Re: [boost] The new Boost 17.0.0

пт, 27 нояб. 2020 г. в 12:46, Hans Dembinski :

...

On 27. Nov 2020, at 09:58, 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.

I am personally fine with a C++17 fork, but that means dropping Boost Serialization among other things, right?

Not really. Serialization library can not be replaced with C++17 Standard library, so we can move it to Boost17. This would require some effort in dropping MPL dependency or replacing it with Mp11, untying it from boost::variant and others

Boost Histogram has level 2 dependencies without Boost Serialization, which is opt-in. With Boost Serialization is has level 18, because Boost Serialization depends on the world. AFAIK rewriting Boost Serialization to drop Boost MPL would be a major effort.

I'm doubting that. A quick search shows that Serialization mostly uses MPL things that are available in C++17 (like enable_if, true_type and static_assert). Effort is required, but it is bearable. Because of that effort we need time to make Boost17 usable. I'd be able to move stacktrace and dll libraries in a few weeks. Mp11, Pfr and Predef are ready to move. It may take much more time to move Histogram or GIL

Besides that, demanding 0 dependencies has serious drawbacks. Boost Histogram uses Boost functionality where there is no equivalent in the stdlib, not even in C++17 (Boost config, Boost throw_exception, Boost mp11, Boost core). I already reimplemented functionality in Boost Histogram that was originally found in other Boost libs to reduce coupling, like Boost Iterator and Boost Multiprecision. Boost Beast does this, too, it has its own variant type and more.

Not 0, close to 0. It is fine to reuse libraries if there is no Standard Library replacement. It is not fine to use Boost version, if there is a close alternative in the C++17

A non-fundamental library like Histogram or Beast has the choice to either suffer a significant loss of functionality or use its own private implementation of Boost functionality to give the appearance of low dependencies. This inflates the private code of these libraries and maintaining private (duplicated) implementations is frankly crazy. We bundle Boost to make use of **synergies** between the libs. I should not use my private (potentially buggy) implementation of Boost iterator, I should use the official maintained (and hopefully less buggy) one.

Yep, we need to keep being reasonable during migration.

Best regards, Hans

-- Best regards, Antony Polukhin