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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-05-23 11:24:40

On 2020-05-23 12:56, Joaquin M López Muñoz via Boost wrote:
> Hi,
> 
> Prompted by general feelings about Boost perceived lack of modernization 
> and internal "bloat",
> and after an explicit survey on what users dislike about Boost [1], I 
> decided to try and write a more
> or less fleshed out proposal for an epoch-based organization of Boost 
> libraries. I've extensively
> tested and refined the proposal during discussions on Reddit and the 
> Boost Slack channel,
> and I feel this is now ready for presentation at the mailing list:
> 
> https://github.com/joaquintides/boost_epoch/blob/master/README.md
> 
> I hope the proposal can start a productive conversation. Looking forward 
> to your feedback.

 From the article:

 > 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 do not think discouraging use of (better) Boost libraries just because 
there is a counterpart in the standard library is a good idea. Using the 
best available tool should be a welcome choice on Boost developers side.

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.