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, because that's, well, unpleasant and an outdated skill that nobody should have to acquire. Even C++11's limitations are quite irritating at times, but C++11 is still miles better than C++98. I'm not young, but I would certainly prefer to write C++11 than C++98.
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.) 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. (And no, the Serialization library isn't obsolete, because it hasn't yet been obsoleted by anything.)