> the compiler can prove that code runs UB, it is invalid code
The *potential* to hit UB is not invalid according to the standard. If it was, then an unchecked array access would be illegal.
If every possible input state for an operation hits UB, then sure the compiler could diagnose that and emit an error. But apart from stuff like type punning, how often does that happen in the real world?
Real world UB pops up in corner cases that weren't considered carefully: What you get weird input and your divisor ends up being zero? What if your string or list ends up being empty? Or, like the example in the article, what if your std::sort predicate encounters a NaN? You might not realize that your code has these corner cases, but the compiler does, and it optimizes assuming that you're aware of these corner cases and assuring it that the executable will never actually hit those corner cases. The compiler can't emit errors for that because it's not invalid code - it might be the intended behavior. The best it can do is a warning.
It boils down to the programmer-language contract on UB being implicit and difficult to grok. Compilers can't fix that.
The *potential* to hit UB is not invalid according to the standard. If it was, then an unchecked array access would be illegal.
If every possible input state for an operation hits UB, then sure the compiler could diagnose that and emit an error. But apart from stuff like type punning, how often does that happen in the real world?
Real world UB pops up in corner cases that weren't considered carefully: What you get weird input and your divisor ends up being zero? What if your string or list ends up being empty? Or, like the example in the article, what if your std::sort predicate encounters a NaN? You might not realize that your code has these corner cases, but the compiler does, and it optimizes assuming that you're aware of these corner cases and assuring it that the executable will never actually hit those corner cases. The compiler can't emit errors for that because it's not invalid code - it might be the intended behavior. The best it can do is a warning.
It boils down to the programmer-language contract on UB being implicit and difficult to grok. Compilers can't fix that.