From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-10-08 11:35:23
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'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.