Re: deprecated: MPL, foreach, typeof, ratio, chrono, assign, more?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-10-08 11:50:28

On 10/8/24 14:35, Andrey Semashev wrote:
> On 10/8/24 03:31, Peter Dimov via Boost wrote:
>> Andrey Semashev wrote:
>>> On 10/7/24 22:16, Peter Dimov via Boost wrote:
>>>> René Ferdinand Rivera Morell wrote:
>>>>> On Mon, Oct 7, 2024 at 11:37 AM Robert Ramey via Boost
>>>>> <boost_at_[hidden]> wrote:
>>>>>>
>>>>>> Fewer younger programmers inspire me these days.
>>>>>
>>>>> Younger programmers are just as capable, and clueless, as I was when
>>>>> at that age. The expectations of the older and older C++ community
>>>>> unfairly expects more than we should be. And in many ways it was
>>>>> easier to "grow up" with the advent of computers and programming.
>>>>
>>>> Age is not the relevant factor here. Forcing people to write C++98
>>>> code in 2024 probably violates the Geneva convention.
>>>
>>> Noone's forcing anyone. Writing C++23 or whatever is pretty orthogonal to
>>> using any of the libraries that were mentioned in this thread.
>>
>> Maybe I was too curt?
>>
>> My point was that if we want people to contribute to our libraries in 2024,
>> we shouldn't require from them to do so using C++98 code[...]
> 
> And we don't. We only require that "A library runs on at least two C++
> compilers implementing the latest ISO C++ standard."
> (https://www.boost.org/development/requirements.html#Portability)
> There's also no requirement that new libraries use specific Boost
> libraries as a dependency, although reasonable code reuse is encouraged.
> (https://www.boost.org/development/reuse.html) The mere presence of the
> older libraries in the list is not a requirement to use them.

I'd like to add to this part that contributors to existing libraries may
be asked to support specific C++ versions, which the library maintainers
have chosen to support. I think, this arrangement is fair and should remain.

>> I'm not young, but I would certainly prefer to write C++11 than C++98.
> 
> Me too, and I share that preference, but this has nothing to do with
> library marking or forcing them on users.
> 
>>> If anything, declaring core libraries deprecated would force downstream users
>>> to seek for alternatives and update their code.
>>
>> The suggestion here wasn't about declaring core libraries deprecated... well,
>> it was, but "obsolete" is a better term than "deprecated". It's about
>> discouraging the use of obsolete libraries in new code. The problem is that
>> when we display the list of libraries, we give no hints to the initiated that
>> a library has been obsoleted by the language (which is the case with Move
>> and Foreach), the stdlib (the case with Bind, MemFn, Ratio, and many others),
>> or by another Boost library (MPL and Mp11.)
> 
> Without further clarification, I don't see much difference between
> marking libraries "deprecated" or "obsolete".
> 
> Again, as a library user, I'm most interested in two things about the
> library: whether it is working, and whether it may potentially become
> unavailable (with varying degrees and ways of "unavailable"). Marking
> the library as "deprecated" or "obsolete" gives me a strong impression
> that it may be removed and it should not be used - whether in new or
> existing (but still maintained) code.
> 
> And yes, I see no real difference between new and existing code in the
> context of using obsolete/deprecated dependencies. As long as I want to
> keep a piece of code working, I would have to avoid using
> obsolete/deprecated APIs in it, regardless of how new it is.
> 
>> Yes, this actually happens; people do sometimes choose to use an obsolete
>> library in error just because our list doesn't make the above clearer.
> 
> Which is why I suggested to add more expanded notices to library docs,
> suggesting more modern alternatives where possible.
>