Breaking all the Eggs in C++
Python 3 broke backwards compatibility and everyone stayed on 2 as a result.  Why is breaking backwards compatibility &quot;for the hell of it&quot; in C++ not going to have the same problem?  Codebases stay in stasis, stuck on older compilers, for far less drastic reasons.  And I&#x27;ve found that modernizing a codebase is a lot easier if you can compile it to test your incremental changes.<p>Talking about a magic wand that makes source-to-source changes on a 100MLOC codebase trivial is pure fantasy - requiring you to ignore that even in the best version control systems, the resulting ~10MLOC merge is going to cause <i>a lot</i> of merge conflicts (some of which will be incorrectly resolved) and history clutter.  To say nothing of all the poor bastards who are satisfied with the occasional tarball per release.  Who are still doing better than the people who can&#x27;t be bothered to backup the code they wrote directly on the server it will run on.  And nevermind the fact that at least some of your downstream customers are still using some old compiler that they&#x27;re stuck with - the only option for some legacy embedded platform they can&#x27;t eliminate yet, made by that company that went out of business.<p>And maybe that kind of cost would be worth it - for the right reasons, given the right motivations.  But I feel like I&#x27;m looking at a laundry list of mostly minor, tiny issues, that are a &quot;solved problem&quot; in the form of existing warnings.  I can crank them up to errors as I modernize a codebase.  You can enable them by default in your build systems and IDEs.  You can mandate them across your organization, and in your contracts.  You can incrementally apply them per library as you get around to doing more maintenance on them.