> Do you think that's an unavoidable law, or is it something accidental that could have gone better? It was the result of having to develop production code in

> Do you think that's an unavoidable law, or is it something accidental that could have gone better? It was the result of having to develop production code in the real world, reusing real world production code developed by third-parties. In my particular case it just so happened that the upstream dependency exported interface headers that conditionally defined stuff with C++14 features in spite of what shipped with their binaries. Stuff using constexpr ultimately resulted in tons of hard to track linking errors. > Would you say a similar minor upgrade of the language version in other languages would have also caused a week of similar hard to debug errors, for a project of the same size? This was not a C++ problem. This was a problem caused by the way this particular project was designed to toggle C++14 features when they should not be toggled. Just because problems emerge when updating a project to the next language version, that does not mean the language is held to blame. This is one of the reasons why I firmly believe half the people in this thread talking crap about software updates and bumping programming language versions are quite frankly talking about stuff they know nothing about and have zero real world experience. There's far more stuff going on in a language upgrade than flipping a switch and rebuilding a project, specially if upstream dependencies made some less-than-advisable decisions on how to release their work.