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
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.