Discussion and better documentation for undefined behavior

[Paul-Andre]

#2402 and #1966 are good. I like the decision to explicitly state that certain operations are illegal.

Some more things to add to the documentation that would be nice:

Defining "undefined behavior" and specifying what the practical implications are. (Can the compiler assume that illegal operations never happen and propagate such assumptions throughout the program leading to unintuitive consequences? Can there be "retroactive" undefined behavior?)

Adding some info on Zig's philosophy regarding illegal operations and undefined behavior. (Some of my guesses: Zig allows to encode more assumptions and intentions into the program than C, so detecting illegal behavior in debug mode is good because it forces you to state what you want. And if assumptions are properly stated there shouldn't be that much illegal behavior happening so full on undefined behavior in release mode isn't that bad.)

Are all instances of illegal operations bugs? Are there things that are said to cause undefined behavior you'd want to do nonetheless? (I'm guessing yes. Then there should be a distinction between illegal operations and operations that access the underlying platform for which the compiler gives no guarantees.)

Finally, and this is more of a question about the design of Zig to Andrew, why make illegal operation cause undefined behavior in release mode instead of some less radical choices? Like simply specifying the behavior (like Rust does for integer overflow in release mode) or having platform-dependent specified behavior (do whatever operation make most sense on the platform) or returning an undefined value. I'm guessing the main argument is to allow as much optimizations as possible. Could you envision a "boringReleaseFast" mode that replaces most occurrences of UB by these other possibilities?

[andrewrk]

Defining "undefined behavior" and specifying what the practical implications are. (Can the compiler assume that illegal operations never happen and propagate such assumptions throughout the program leading to unintuitive consequences? Can there be "retroactive" undefined behavior?)

Covered by #2402 and existing documentation of undefined behavior / build modes.

Are all instances of illegal operations bugs?

Yes

Are there things that are said to cause undefined behavior you'd want to do nonetheless?

No

why make illegal operation cause undefined behavior in release mode instead of some less radical choices?
Could you envision a "boringReleaseFast" mode that replaces most occurrences of UB by these other possibilities?

See release-safe build mode.

[Paul-Andre]

release-safe mode uses runtime checks.

What I meant was a mode that removes runtime checks and replaces them by predictable but possibly platform-dependent behavior.