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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-05-25 12:06:48

On 2020-05-25 14:42, Alexander Grund via Boost wrote:
> 
>> 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?

And if Boost.FooBar wants to support C++03 for some reason then you 
would mark it Boost03 only. This is bad PR for no reason.

Again, if you want to give users a way to reduce dependencies then work 
on that. This is a technical task. Work on modularization, 
documentation, configurability, reducing the cost of C++03 support, etc. 
Tagging or otherwise ranging libraries is not involved in any of this, 
and C++03 (or any other) libraries are not penalized in the process.

> Or make users come up 
> with own implementations for the 100th time because "the compiletime 
> performance of Boost sucks".

That's their right and their decision. I bet you many users will still 
find reasons not to use Boost or any other libraries, really. That's not 
to say Boost doesn't need to improve or has no problems. It's just don't 
expect people to stop reinventing the wheel.

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

If you mean "dropping support for C++03" by that then yes, that is one 
way. Maintaining backward compatibility and using Boost.MPL because of 
that is another, and it must be as viable option as others.