This is a good change. Potentially ambiguous to read syntax is being made clearer in a way that harms no previous code substantially.

I sometimes wonder if the comments that say nothing more than "C++ is too complicated" are from people who use it regularly, much less people who are even commenting on TFA

I don't fully understand the connection between your two paragraphs. It's not inconsistent for the language to be too complicated for it to be a good change.

I'm also not totally convinced that someone not using a language regularly means their view on it being too complicated must be invalid; I would fully expect someone who views it as too complicated to try to avoid using it, and there are enough people doing that, it might be a cause for concern. That doesn't necessarily mean they're right, but without further context it also doesn't mean their opinion isn't relevant.

What is a teapot?

I cannot make one of those.

Refrigerator.

Can't pass a PhoneNumber to a function expecting an EmailAddress, for one, or mix up the order of arguments in a function that may otherwise just take two or more strings

Dates are unfortunate in that you can only really parse them reliably with a TZDB.

Nitpick: icons are about signifiers, not affordances. A button affords being pressed, an icon on the button signifies what pressing it will do.

In context, binary breakup and binary fracture apppear to mean a splitting ofa whole into two parts along a given line or plane

Since the optimiser is allowed to assume you're not invoking UB, and strlen of null is UB, I don't believe that it would consider that case when optimising this function.

I understand that, but I don't agree that such optimizer behavior is worth it and I won't put it in my compilers.

I appreciate that greatly.

The notion that because it is undefined behavior means that the compiler is free to replace it with anything up to and including "launch nuclear missiles". This is just nuts.

If I program it to cause a null pointer seg fault, I expect a null pointer seg fault. If I program it to cause a twos complement overflow, I want a twos complement overflow.

Yeah, I feel the same way. It's refreshing to hear that that's not just because I'm insane. I think C compiler teams are sort of forced into this stupid shit because they don't have new CPU architectures to port to anymore, so, unless they want to go find new jobs, they're forced to waste their time and everyone else's by "improving" the compilers by increasing performance in riskier and riskier ways.

You mean the same problem that the article is trying to solve in C? Generic data structures?

"Just FYI I have a PhD in cosmology" is the credentials for the poster being an expert.

That would certainly catch nearly all migration issues, but it doesn't provide a helpful error message like a test for a specific mistake like this does.

Ideally both approaches would be used, with the general case being used to detect and inform more targeted tests.