Breaking all the Eggs in C++ (2015)

For the transition from Python 2 to 3 the Python team released just such a conversion tool, aptly named "2to3." [1] This was better than handy but the transition from 2 to 3 was still lengthy and painful. In practice many of the suggested changes were unnecessary or at least needed human review (e.g. suggesting changing "for n in range(1,11)" to "for n in list(range(1,11))". Thanks, 2to3, but that code is still correct and actually faster with the iterator version of range().) Another problem was that, just like it says on the tin, 2to3 produces a version of code that only runs under Python 3, whereas most library authors during the transition time wanted a version that would run under both 2 and 3 a la the six[2] library.

So while a one-way automated refactoring script sounds like a good idea, and is strictly better than just breaking backwards compatibility and expecting everyone to deal, it wasn't an unqualified success for Python.

[1]: https://docs.python.org/3/library/2to3.html [2]: https://pythonhosted.org/six/

You can't remove features from a language, that creates a new language instead. The transition then takes years. Haven't people realised this since the Perl 5/6 and Python 2/3 transitions?

If everyone just runs a static analyzer after compiling you could have best of both worlds. For example the tool would complain if you don't use 'override'. Problem is that not everyone runs the same tool. So at work I would like to compile with (for example) -Wconversion (warn about implicit conversions that lose precision). But this is impossible because Qt headers raise so many warnings on this. And because C++ has no module system I can either 1) fix all of Qt or 2) don't add the warning and keep writing old C++. I think you can guess what I will do.

Anyone who has programmed with Objective-C (or Swift) for years knows Apple's language deprecation cycle. Write code one year, the next year you are flagged with a deprecation warning -- Xcode of course will help you upgrade your code. Your unchanged code will probably work for another year and then suddenly it is an error. The "magic wand" of Xcode / Clang helps you thru this transistion. Apple likes to break eggs.

Scott Meyers overlooks one problem with his quest to kill backwards compatibility: upgrading compilers is a no-go for many safety critical codebases. The re-certification of the code for released products would have to be repeated in its entirety - a sneaky bug or behavior change in the new compiler might introduce any number of issues. That isn't going to fly for cost reasons. This effectively freezes shared code between products at these ancient language standard levels.

Discussed at the time: https://news.ycombinator.com/item?id=10562105

> Just replace the use of ++ with an assignment from true.

You can't just replace it with assignment to true directly as postfix ++ evaluates to the unmodified value; you actually need to replace b++ with something like (b?true:(b=true,false)) to avoid breaking code that uses b++ in an expression. That seems significantly uglier than just allowing b++ to continue to exist though...

This sounds like a terrible idea. You can provide a way for people to opt out of legacy behavior, but don't break them outright unless you want to lose your most faithful, long-term users.

> All we need is a magic wand that works instantly and flawlessly.

> That makes clang-tidy, if nothing else, a proof of concept.

More like a proof of failure. Apply clang-tidy's transformations to source code and now you've now got one gigantic merge conflict to resolve every time you merge from upstream. That's partially fixable if you script your integration, or your integrators have good checklist discipline (they don't) and apply clang-tidy to new upstream commits before trying to merge them, and you've properly documented that.

Downstream is more problematic. And in my experience, large merge conflicts like this are just begging for hard to spot bugs introduced by mismerging commits - much more common than I've noticed bugs from passing 0 to pointers or NULL to non-pointers. To add insult to injury, it'll fail to finish the job - for example, trivial edge cases like 0 being used in a macro which is interchangeably used to initialize ints and nullptrs depending on context - so now you need manual intervention to actually fix up the code enough to actually "break the egg".

Not to mention NULL in C headers, as mentioned in the blog comments, being not a great thing to get rid of.

> Experience shows that relying on compiler warnings to inform programmers about "bad" practices is not reliable.

Get a bigger CI build matrix. This is a criticism of the implementation, and perhaps those who don't use warnings-as-errors - they have much bigger problems than a confusing 0/NULL/nullptr trifecta though. Standardize some warnings? Sure! We've been adding things like [[nodiscard]] that, while still not requiring warnings, strongly encourage them to the point of being just a hair's breadth away from standardization.

Several compilers don't even like enabling new warnings by default - hence the -Wall -Wextra -Weffc++ -pedantic -etc -etc -etc dance, which still doesn't get everything you might want. If you want to change the culture around that so we opt out of warnings instead of opting in, sure, I'm on board with that. We already have the tooling to crank those up for your own code while using more permissive settings for third party code you'd rather not modify/break.

If you can't convince compiler vendors to warn more by default, you're going to have even less luck getting them to break code by default (unless you can trick them into thinking it's an optimization).

TL;DR: We've got more reasonable, less drastic tools. Maybe push those to be used more efficiently, instead of inviting a new Python 3 fiasco. I'm sure I'm not the only person who would jump to Rust (or Go, or Nim, or ...) instead of to C++vIncompatible - because if you're going to make a breaking change, why not break enough things to make it worthwhile?