I feel like a development such as the C++ standard needs to deprecate things a lot faster than they currently do. Imagine in 15 years time when C++ compilers are so complicated that they become self-aware and decide to get rid of us programmers.
This, a thousand times. It's all very well for gumby to say that C++ is a big toolbox, but a good toolbox doesn't have all the mismatched tools from ten previous toolboxes all thrown together. Longcommonname can say that using modern C++ features help prevent errors, but that statement becomes a bit problematic when the most modern C++ style becomes deprecated C++ every few years. As the OP aptly illustrates, there are just too many ways to do even fairly simple things. All were idiomatic "best practices" for their time. It's not a problem if there are many ways to do things if they're all comprehensible to someone who knows the universal core of the language (as is often the case e.g. in C or Python). It's a problem when understanding each of them requires a whole separate excursion through some separate specialized and time-bound part of the standard, yet they all exist together in any large codebase that has had to build on those shifting sands. That's not good for maintainability. Future programmers will misunderstand the intent of code using each transient style, and either break it when they change it in place or miss some important detail when they try to replace it.
Different versions of C++ should remain separate to a much larger degree than is currently the case. Trying to combine several distinct language-as-written into a single super language-as-compiled (a mistake also made by Scala) never seems to work out very well.
Yes, you can have major breaking changes every few years. But do you really think every larger C++ code base being stuck with the C++ version it was founded on is the way to go? Should they all be rewritten for each version?`
Don't get me wrong, I'd love if we could deprecate more old stuff. The problem is that it doesn't just disappear from existing code (of which there is a _lot_) by marking it as such. If there are straightforward replacements (e.g. auto_ptr -> unique_ptr) that's one thing, but unless you want each new C++ standard to be unusable with existing code, you can't just do that.
Yes. It's the codebase for one of the largest data storage systems in the world. If it stopped working, literally billions of people could be affected. Is that good enough to get past the ad hominem?
> past the idealism.
Is the idealist the one who questions the wisdom of changing a codebase that already works, or the one who demands it? It's all too easy to accuse others of being too idealistic, or to make up strawmen (see next point), but I don't think those are very constructive ways to approach a discussion.
> do you really think every larger C++ code base being stuck with the C++ version it was founded on is the way to go?
Of course not. But the transition from old idioms to new ones can be managed. The first thing that has to happen is that the people adding new features to each standard must be explicit about which old features are being deprecated when. Sure, you can specify --std=c++25 to get the new hotness, but then that might preclude use of old feature xyz from C++11 in the same compilation unit. You have to choose, and you should choose, according to pragmatic needs instead of mere neophilia.
> unless you want each new C++ standard to be unusable with existing code
Controlled deprecation doesn't necessarily mean 100% incompatibility between versions. N-1 is a very common model, which can be extended across any K prior releases. There are tons of examples, not only from languages but from APIs, file formats, operating systems, and even other kinds of engineering besides computers. People should absolutely be given time to adjust, but the time should be finite. "Simultaneously support everything that every existed" is the one model that's least likely to work in the long term.
Regrettably they typically do, as well as three kinds of the same kind of screwdriver, with slightly different lengths (c++'s equivalent would be 'for', 'while' and 'do..while'.). One of the appeals of a new language (e.g. rust) is that you don't start with the legacy boat anchors...yet (look at Python or perl).
I don't think there's a very good solution.
Go tried to go the other way by explicitly not having lots of affordances. Personally I'm not a fan but I can see the logic.
Yeah, true. Maybe the better analogy is not the toolbox but the screws, bolts, etc. that the tools operate on. I have several sizes of Torx and other exotic screwdrivers which I have never needed ... but I might some day, if some idiot who knows where or when decided that they just had to use that particular screw for something. In large long-lived C++ codebases there always seems to be some asshole who used the equivalent of a MorTorq or Tri-Wing just because it looked cool, so that feature has to be supported forever after. Programmers years later then see this far from self-explanatory code, because these additions always seem to involve using familiar symbols in arbitrary new ways, and have to pore through old versions of the standard to figure out WTF it does. I do think it would be far better if the old screws and the drivers for them were deprecated from time to time.