On 5/26/2020 10:20 AM, Joaquin M López Muñoz via Boost wrote:
El 25/05/2020 a las 21:32, Edward Diener via Boost escribió:
On 5/25/2020 12:38 PM, Joaquin M López Muñoz via Boost wrote:
El 25/05/2020 a las 14:06, Andrey Semashev via Boost escribió:
Maintaining backward compatibility and using Boost.MPL because of that is another, and it must be as viable option as others.
It's a viable option, but then the lib won't get into Boost11, unless Boost.MPL inclusion is conditional on BOOST_ASSUME_CXX. Not being in epoch Boost11 does not mean the lib can't be actively maintained and work in C++11 and later (which is mostly the case for C++03-compatible code).
I think you need to explain in your document that the criteria for a library to be in an Epoch level of c++11 on up is that the library depends on a C++ standard library rather than its Boost equivalent in any cases where this dependency might exist, as well as the fact that the library depends on other Boost libraries, in any cases where this dependency might exist, which themselves follow the C++ standard versus Boost library criteria. I personally would support such an idea for Epocjs. But I would want the decision based on the Epoch to which a library may belong to be solely based on this objective criteria, and not on any subjective idea of what constitutes a C++nn library or not.
Yes, in the context of the proposal you're referring to so-called "rejection rule 2", which is practically custom-made for the case of Boost.MPL. I personally find that this lib, which was a breakthrough back in the day, now it's too much of a burden in non-C++03 environments, given the much lighter alternatives.
If epochs were ever a reality, I'd vote for deferring the exact decision on which "core" libraries promote to one central authority (the BSC, most likely), because there'd be controversy one way or another. This is just speculation right now, though.
I think the idea of a set of Boost libraries: 1) which do not have a C++ standard library equivalent 2) which do use one or more Boost libraries which do have a C++ standard library equivalent 3) producing an alternative version of an individual library which uses the C++ standard library equivalent(s) would be useful for end-users who want to use Boost in a C++11 on up environment where C++ standard equivalent libraries are being used. This is not a criticism in any way of any Boost libraries which have C++ standard library equivalents but rather an acknowledgment of the fact, suggested by cxx_dual originally, that end-users in C++11 on up environments most probably want to be able to consistently use the C++ standard libraries rather than to have to mix their use of such libraries with Boost equivalent libraries. But of course who would do the work, even given that a consensus were formed that this would be valuable to Boost in general, of creating alternative versions of all those Boost libraries, since many of those libraries are barely maintained as is in regards to issues and PRs, much less alternative versions meeting such a goal ?