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