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

From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2020-05-24 08:40:14

El 23/05/2020 a las 13:24, Andrey Semashev via Boost escribió:
> 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.
>

Boost.Regex is admittedly a controversial point (as mentionedin the 
proposal) due to its
superior quality to some std implementations. But there are other 
components whose usage
I find it hard to justify, such as Boost.Array and Boost.Tuple (there 
may be others).

Whatever the intrinsic qualities of these foundational libraries, they 
seem to totally be
losing the PR battle against std counterparts (if that was a battle to 
begin with, that is):

https://github.com/joaquintides/boost_epoch/blob/master/boost_vs_std.md

> [...]
>
> Next, I disagree with the idea that a library could be "not allowed to 
> progress". Why block
> further improvements and extensions?

In the section quote from, "progress" means "be given the newer epoch 
badge". I'm not
referring to preventing the author from evolving their lib, which is 
their unalienable right.

> 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. 

The crucial point here is to what degree this extra functionality in 
Boost.X is actually used by other
Boost libraries when Boost.X is a dependency. I don't have hard data 
(you don't provide any either)
but I suspect this degree is very low.

On a more philosophical note, one of the goals of Boost is:

"We aim to establish 'existing practice' and provide reference 
implementations so that Boost
libraries are suitable for eventual standardization."

In this regard, Boost has been extremely successful up to C++11, 
moderately so ever since.
But one aspect that wasn't planned or even discussed when Boost started 
22 years ago is:
what do we do after standardization. Epochs is one answer to that. 
Regardless of the merits
of this proposal, I think we owe ourselves a discussion around this 
central topic of coexisting
with an evolving standard that is expected (and helped) to take over 
much of the user base of
components originated outside.

Joaquín M López Muñoz