If P1236 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p12...) is really what it says ("alternative wording") then I don't believe that's true. Certainly P0907R3 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09...) is clear:

> Status-quo If a signed operation would naturally produce a value that is not within the range of the result type, the behavior is undefined. The author had hoped to make this well-defined as wrapping (the operations produce the same value bits as for the corresponding unsigned type), but WG21 had strong resistance against this.

My understanding is that the 2s complement change in C++20 ended up defining bitwise operations but not arithmetic.

Two's complement does not mean signed overflow became defined. So the check is still wrong. And no, I do not think making it defined would lead to more correct programs. You then simply have really difficult wrap-around bugs instead of signed overflow which you can be found more easily with UB sanitizer or turn into traps at run-time.

It made the switch, sure, but overflow remains undefined.