[skitter]

I agree with your point about Python, which is why I'm glad type hints see adoption but dismayed that they're essentially fancy comments that don't enforce the actual runtime types.

The thing is, I'm not convinced avoiding UB is easy. E.g. what's the behavior of the following code?

    int16_t a = 20000;
    int16_t b = a + a;

[lumb63]

Agreed on the dismay regarding type annotations. My opinion is that potentially misleading code which gives a sense of safety when none exists is worse than dangerous code. It lowers the programmer’s guards, which can lead to more bugs.

Integer overflow will result, I’m pretty sure. The largest value a signed 16 bit (so, 15 bit) can hold is 32767, IIRC.

I can see where that’s unexpected for people whose brains aren’t wired in powers of 2. This is one area where I think Rust improves upon C, with its availability of overflow detection in arithmetic. It’s unfortunately verbose, but it enables greater safety.

[skitter]

Not quite what I was getting at: On an implementation with 32-bit ints, the code is valid – the values get promoted to 32 bit, added and then truncated to 16 bit. Yet on a platform with 16-bit ints (and microchips & unusual platforms is a frequently stated reason for using C), the addition overflows and result in UB.

Luckily most other languages haven't decided to copy C's implicit promotion rules & target-dependant integer sizes.

[jcranmer]

Given that all arithmetic autopromotes to int if smaller than int, there's no undefined behavior in this code if int is 32-bits (which is true on most systems).