Most compilers, like gcc or clang, have a compile option to trap on integer overflow, instead of leaving the behavior to be undefined for such cases.

For example with gcc one should always use these compile options, unless there exists an extremely serious reason to do otherwise:

-fsanitize=address,undefined -fsanitize-undefined-trap-on-error

These options provide correct behavior not only on overflows, but also on out-of-bounds accesses and other C undefined operations.

It’s fine for debug builds, but people should be aware that building with the address sanitizer enabled balloons the size of the executable and slows it down tremendously.

One should always measure to see if there is a noticeable slowdown or not.

That is what I have meant by "an extremely serious reason to do otherwise".

For many programs the speed is determined by things like the throughput or latency of accessing the main memory, or by I/O operations, or by interaction with an user, in which case the sanitize options have negligible influence on speed.

When necessary, they should be turned off only for specific well tested functions whose performance is limited by CPU computation in registers or in cache memory, and they should remain on for the rest of the program.

ASAN can easily slow your program by 100x or worse. Your bias should always be that its impact would not be acceptable in production. If you were willing to accept the cost of ASAN you should have simply chose a slower, safer language in the first place.

I don't understand. It sounds like you're describing the existing behavior for the existing types. But I'm asking for new types with new behavior. The rules could be defined behavior for these types, which is what I want. I don't want types that happen-to-trap-because-it's-UB. I want a type that traps because that's its mission. And another type that saturates.

I understand the existing undefined behavior, that's not particularly interesting. What would be interesting is well-defined behavior for new types that does not interfere with however defined or undefined behavior exists for the existing types.

> usually do not have separate opcodes for overflowing arithmetic operations and trapping arithmetic operations.

I don't care how good or bad the codegen is. Just emit the code for the right behavior, because I'm using this type that requires this behavior.

> The issue is that unsigned integers must not trap on overflow

You forgot to add 'in C', in Zig they have the same behaviour as signed integers.