The new Boost 17.0.0

From: Mike (mike.dev_at_[hidden])
Date: 2020-11-27 12:05:11

> Gesendet: Freitag, 27. November 2020 um 11:36 Uhr
> Von: "Andrey Semashev via Boost" <boost_at_[hidden]>
>
> 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