Re:C++17 – better than you might think
by FreezerburnV on Thursday December 29, 2016 @11:14AM
(#13278085)
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.
Re:C++17 – better than you might think
by daurnimator on Thursday December 29, 2016 @11:08PM
(#13282444)
> 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.
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.