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.