Breaking all the Eggs in C++ (2015)
&gt; All we need is a magic wand that works instantly and flawlessly.<p>&gt; That makes clang-tidy, if nothing else, a proof of concept.<p>More like a proof of failure.  Apply clang-tidy&#x27;s transformations to source code and now you&#x27;ve now got one gigantic merge conflict to resolve every time you merge from upstream.  That&#x27;s partially fixable if you script your integration, or your integrators have good checklist discipline (they don&#x27;t) and apply clang-tidy to new upstream commits before trying to merge them, and you&#x27;ve properly documented that.<p>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&#x27;ve noticed bugs from passing 0 to pointers or NULL to non-pointers.  To add insult to injury, it&#x27;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 &quot;break the egg&quot;.<p>Not to mention NULL in C headers, as mentioned in the blog comments, being not a great thing to get rid of.<p>&gt; Experience shows that relying on compiler warnings to inform programmers about &quot;bad&quot; practices is not reliable.<p>Get a bigger CI build matrix.  This is a criticism of the implementation, and perhaps those who don&#x27;t use warnings-as-errors - they have much bigger problems than a confusing 0&#x2F;NULL&#x2F;nullptr trifecta though.  Standardize some warnings?  Sure!  We&#x27;ve been adding things like [[nodiscard]] that, while still not requiring warnings, strongly encourage them to the point of being just a hair&#x27;s breadth away from standardization.<p>Several compilers don&#x27;t even like enabling new warnings by default - hence the -Wall -Wextra -Weffc++ -pedantic -etc -etc -etc dance, which still doesn&#x27;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&#x27;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&#x27;d rather not modify&#x2F;break.<p>If you can&#x27;t convince compiler vendors to warn more by default, you&#x27;re going to have even less luck getting them to break code by default (unless you can trick them into thinking it&#x27;s an optimization).<p>TL;DR:  We&#x27;ve got more reasonable, less drastic tools.  Maybe push those to be used more efficiently, instead of inviting a new Python 3 fiasco.  I&#x27;m sure I&#x27;m not the only person who would jump to Rust (or Go, or Nim, or ...) instead of to C++vIncompatible - because if you&#x27;re going to make a breaking change, why not break enough things to make it worthwhile?