If you're actually working with C++, old "misfeatures" simply aren't something which gets in your way very often. You can just code in the modern way and be happy.
The problem then is that some of the advantages of modern C++ are a bit "all or nothing". Just to pick an example, for exception safety in the current sense to really work, basically all of your code has to be written in a certain style, which is something that's really hard to achieve.
Maybe that's less of a problem for codebases started after 2011 that have been written in the modern style from the beginning. But given the way the C++ language continues to evolve, my bet is that even those will eventually run into the same problem with whatever new feature is introduced in 2026. There really needs to be a way to deprecate old language features.
That's one of the things I think the golang project did right. The gofix tool can be used to update old codebases.
No language that lives long enough is safe from it.
As a related question: I seem to vaguely recall some mention by someone on HN, that somebody is trying to get some kind of "safe/strict blocks" markers into C++ (or some compiler? I have the feeling it was to be MSVCpp?), where "misfeatures"* would be disabled. Is anybody aware of something like this? Or was that just a beautiful dream I had?
* -- for some unknown definition of "misfeatures"
You could argue that anyone who wants that is already on Rust or whatever, but I bet there are plenty of people who like modern C++ and don't necessarily like Rust.
These aren't mutually exclusive groups. I'm a professional C++ programmer posting on HN to say that C++ is terrible, even when you can somehow confine yourself to "modern C++" -- presumably because you're free from legacy code originally written in the 00s, or earlier!
C++11 (and to some extent C++14) made C++ less awful, but it's still a turd. And even many of the best features of C++11, like move semantics, are blown away by their equivalents in Rust. By the way, even whenever concepts and concepts finally land (I've given up now), C++ templates are still going to miles behind Rust's trait-based generics in ease of use and readability.
Every feature/syntax added to C++ is one more place mistakes can happen, and one more thing to watch out for when debugging. I wish there was someone in a position of C++ power pushing to remove a feature for each one added.
It is fine to deprecate small warts if there is an obvious semiautomated path forward or if are hardly used (auto_ptr, trigraphs), but things like ADL are very unlikely to be ever fixed completely.
I don't see what's inherently wrong with deprecating and then removing features or standard library templates in newer standards. As long as compilers and library implementations continue to support the old features when you ask for an old standard (by passing `-std=c++11` or whatever), what's the problem if C++26 removes $BAD_FEATURE?
The standards committee doesn't seem to think there's an absolute problem with removing features or standard library templates, because they've already removed trigraphs, auto_ptr, and more in C++17.
It is not just a theoretical issue btw, unfortunately compatibility breaks do happen outside the standard, especially during the early to mid 2000s as compilers started enforcing the standard more closely; enforcing two phase lookup has been particularly painful and I don't think anybody is willing to repeat that experience very soon; there are still codebases stuck on Visual Studio 6 which was infamous for its nonconformance [1] and was widely popular in the late 90s till the early 2000s.
[1] to be fair it parially predates the standard.
Probably would be nasty to maintain for the compiler developers though. Imagine having to do a bugfix for c++11 mode when you just released c++26 mode.
They already have to.
What you're proposing makes much more sense: it means if you write a C++26 only compiler, you don't have to worry about implementing all the old crap that no sane person uses.
This is true, in lots of ways. Lots of code is rushed, corners cut, so was bad the moment it was written. Other code is written in a particular style, and would need to be cleaned up to match a more modern style.
One benefit of backwards compatibility within one language is that these pieces of code can be improved incrementally, without having to switch languages. So, a road to improvement, rather than a source of mistakes.
The key is to make the new code better than the old code!