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