And for those existing multi-milion line projects, which are often decades old, you certanly do noy want to break backward compatibility. Ever.

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.

> And for those existing multi-milion line projects, which are often decades old, you certanly do noy want to break backward compatibility. Ever.

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.

Those multimilion lines of code are not just legacy codebases, they are often continuously updated and slowly dragged in the 21st century by using more modern idioms and embracing newers standards. If c++11 and 14 had significant compatibility breaks, they wouldn't have had the uptake they did and would have split the community.

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.

Theoretically you could remove features by deprecating them (with warning) for a specific c++xx version, and removing them in the next. So if c++14 warned on some $BAD_FEATURE, and then $BAD_FEATURE was removed in c++17, there is still a migration path from c++11 to c++14, and eventually c++17 once all deprecation warnings are removed. (or even before, if someone wants to take the time to remove any remaining warnings in one shot) If the compilers were then able to support the exact set of warnings/removals per version by a flag, old codebased would continue to compile and theoretically would continue to move into more modern features as the next version would never actually break the code.

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.

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

> Not everything is a new cleanly constructed codebase.

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!