terminology update: use the phrase "detectable illegal behavior" rather than "safety-checked undefined behavior"

[andrewrk]

The language reference makes use of the phrase "safety-checked undefined behavior" to mean "that which is undefined behavior in ReleaseFast and ReleaseSmall modes but will panic in Debug and ReleaseSafe modes".

This is a bit problematic because in the safe build modes, it's actually completely well-defined behavior. It will call the panic handler. Further, it will cause confusion because many people see "undefined behavior" and think it's a weakness of the language, when really it's the opposite - e.g. catching integer overflow bugs wouldn't be possible if it were always defined to be two's complement wraparound arithmetic.

I think a better phrase would be "illegal behavior". Illegal Behavior is always Undefined Behavior in the unsafe build modes. Illegal behavior at compile time is always a compile error. In safe build modes, runtime safety checks attempt to detect illegal behavior, but not all kinds of illegal behavior can be detected. Detected illegal behavior is well-defined and calls the panic handler. Undetected illegal behavior is undefined behavior, even in the safe build modes.

Instead of "safety-checked undefined behavior" the docs would say "detectable illegal behavior".

Related: #1966 #2301

[Paul-Andre]

I'd use some other word instead of behavior to distinguish what you're asking the program to do and what it actually does. Perhaps "illegal operation" (an illegal operation causes undefined behavior).

[matklad]

Another language lawering argument for this: even if a hypothetical future alternative implementation of Zig defines some of these behaviors, we still want to declare them to be incorrect, and any program making use of them buggy.

[matklad]

the docs would say "detectable illegal behavior".

This is splitting hairs and I am not at all feeling strongly, but maybe just "checked illegal behavior"?

• It is simple
• It is more precise. detectable leaves the possibility open that the behavior isn't actually detected, while checked implies that it is always defined to trap (in release safe).