Gesendet: Freitag, 27. November 2020 um 11:36 Uhr Von: "Andrey Semashev via Boost"
On 11/27/20 11:58 AM, 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.
ะก++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".
We went over this multiple times. I'll just reiterate that I disagree with this approach. Many Boost libraries are superior to std equivalents, and I want to keep using them inside and outside Boost. Also, I don't see why Boost libraries are not allowed to exist as an extension over the std equivalents.
Speaking for me in particular: What does annoy me, is if a boost library uses the boost equivalent of a standard library vocabulary type in its interface. E.g. boost::string_view instead of std::string_view or boost::chrono::duration instead of std::chrono::duration. As far as other duplications go: If (and I really want to stress the if) using the boost version adds significant compiletime or binary size overhead compared to the std version then I'd also prefer if the std versions were used in the implementation where possible. Otherwise I as a user don't really care. The difference in compiletime might happen when the boost version using some complex TMP (especially mpl) hacks whereas the std version can use more efficient language constructs - and of course the std version almost always ends up in my translation unit anyway, so compiling the boost equivalent is just some additional work, but I don't have any experimental data to show if there are actually any significant gains possible inpractice. Regarding the proposal in general: Let me play the devil's advocate and ask, how many active boost maintainers there are left. Are there enough to pull through with something like that, without loosing a big chunk of the libs for which there isn't a good c++17 equivalent yet (or ever). Actually, that would be an argument for removing internal dependencies on boost libs that have a c++17 equivalent: Reduced overall maintenence overhead for boost once you are there and more flexibility for individual libs. But of course I'm certainly not able to predict, if it would be a net win or not. Best Mike