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.