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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-05-25 10:41:30

On 2020-05-25 13:06, Alexander Grund via Boost wrote:
> 
>> 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

What I'm saying is most of the libraries that were adopted by the 
standard have features that were not (yet) adopted. And prohibiting 
further evolution of these libraries beyond the standard set of features 
is not a wise decision.

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

Note that we don't have a technical reason for adopting any kind of tags 
for libraries. The proposal is primarily targeted at solving the PR 
problem of Boost. Saying that a library is Boost03 (and not Boost11 and 
later) is not solving the PR problem for the library, it's creating one.

If you're really are concerned about technical deficiencies of some 
libraries (e.g. Boost.MPL) then the right solution is to work on 
improving those libraries.