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

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-05-27 08:32:39

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 ?