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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2020-05-25 11:42:51

> 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.
What I'm saying is there is no one prohibiting anything. The epoch is 
only a label which correlates with "reduced bloat", you don't "need" it.
> Note that we don't have a technical reason for adopting any kind of 
> tags for libraries. 
Correct. Those tags are meant as an incentive
> The proposal is primarily targeted at solving the PR problem of Boost. 

Yes, by improving the most often named problem of Boost: Unnecessary 
compile time increase. Example from recent reddit:

 > of the major problem we had with Boost was that its use had a big 
impact in the compilation time, mostly due to the many headers and 
templates to parse and to the symbol duplication in the object files
https://medium.com/@julienjorge/testing-c-signal-slot-libraries-1994eb120826

> Saying that a library is Boost03 (and not Boost11 and later) is not 
> solving the PR problem for the library, it's creating one.

No. It is improving the performance (overall) of Boost11 and up, 
produces good PR for those while giving users and developers a hint on 
what the library relies on

Again: If e.g. Boost.Atomic is enhanced and improved over the 
std-counterpart and Boost.FooBar needs these enhancements then it can 
use it. But if Boost.FooBar does not need those or if Boost.Atomic does 
not provide any benefit (anymore), then why pay the cost for the 
additional dependency which is paid by all users? Or make users come up 
with own implementations for the 100th time because "the compiletime 
performance of Boost sucks".

> 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.
Again, the point is to reduce dependencies. So the "technical 
deficienc[y]" in most cases is the usage of another boost library alone. 
And in the case of MPL: The solution already exists and is called Boost.MP11