Re: [epochs] Proposal for an epoch-based organization of Boost libraries

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2020-05-25 10:06:55

> > if you were writing a new candidate Boost library with C++11 as its 
> baseline, would you strive to use std components rather than their 
> Boost counterparts, no matter how good the latter are? I would say you 
> would.
>
> I would not. As a user (either in-Boost or external) I would choose 
> the library that is technically better. Boost.Regex is actually a very 
> good example of such, as it is considerably faster than at least some 
> popular std::regex implementations. There are other examples where 
> Boost equivalents are technically better in one regard or another than 
> the standard counterparts.
I think this is the point with using any dependencies: Is the added 
value (in performance, features, ...) worth the cost (compile time 
increase, maintaining compatibility, ...)
And as stated above: Using a stdlib part is not considered a dependency 
by most.
> Next, I disagree with the idea that a library could be "not allowed to 
> progress". Why block further improvements and extensions? Take 
> Boost.Atomic or Boost.FileSystem, for example. These libraries are not 
> equivalent to the standard counterparts, and offer extensions that are 
> useful in practice and cannot be efficiently implemented "on top" of 
> the standard components. What would be the point of a Boost.Atomic v2 
> if it had to reimplement Boost.Atomic? We are spreading our time thin 
> as it is already.
>
> The above examples are not an exception. I think, almost every library 
> that was adopted by the standard is not equivalent to the standard 
> component. Some of them have continued to evolve since adoption, and 
> results of this evolution may be adopted by the standard in the 
> future. I see no point in creating new versions of such libraries on 
> each iteration of such adoption.

There is no reason. The point of the proposal is to reduce dependencies 
and hence "bloat" most users complain about. Boost.Atomic can stay 
Boost03 and be fine. If it has features the std variant does not have 
AND does not use other Boost libraries subsumed by the std then it would 
even be considered part of Boost20

 > The Microsoft STL is now open source (I'm sure you've all heard about 
it), So in the case of Microsoft, it suffices to create a PR and 
upstream the better boost library

Sadly not. It mustn't break ABI. Example: I proposed they implement the 
never-valueless variant for cases where this is possible the same as 
GCC/Clang do, but it was refused due to ABI. So good luck with 
boost::regex...

 > User perceptions about bloat may be related to the download size.

It is also about compile times and binary size. Using MP11 over MPL 
reduces the former, using std:: types over boost types (may) allow to 
generate less code as template instantiations of the types in use are 
also used in user code already. So using `std::optional<bool>` in user 
code and `boost::optional<bool>` in boost internals or interfaces means 
twice the code for the same functionality (unless references inside are 
used of course)

 > But I fear that (like other projects like Cmake) the BIG hurdle that 
we struggle to get over, is *resources*.

This is the main point of the proposal: It is a gradual way. Lets say it 
is "switch to C++11 - lite". No one is forced to do anything but 
developers are incentivized to drop dependencies where possible and 
there would be a way to measure progress. This can happen 
Boy-Scout-Rule: Where you fix stuff, clean/update the surroundings. 
Gradually you'll have a "clean"/updated library

 > Tests and tests data are another area that many users rarely use, but 
separately them would be a big task.

Sorry? Simply remove all test folders before uploading the tarball. 
Done. For the tests-release: Simply remove all folders BUT the test 
folder. The names are standard already so that is easy.

 > Boost.MPL and Boost.Mp11 are very different in API, which means that 
a library that uses template metaprogramming and wants to support C++03 
and later cannot be compliant with the Epoch requirements, unless it 
contains two versions of the TMP code

That is one of the points of the epoch proposal: MPL has known 
shortcomings (mostly compiletime) that are "fixed" in a C++11 library 
(MP11). So the authors/maintainers are incentivized to drop the MPL 
dependency for MP11. if they don't because they care about C++03 (from 
your statement above) for some reason, they (rightfully) don't get a 
badge saying "Boost11". So what? No harm done except C++11 and up users 
know the lib uses some old/slow dependency and can decide to not use it 
if they don't deem this useful enough to offset the cost (see top)