6 ms·

You picked that quote from the main page, not from the release notes, here is what directly follows: * The reference implementation uses LLVM as a backend for

by lkey 7y ago

You picked that quote from the main page, not from the release notes, here is what directly follows: * The reference implementation uses LLVM as a backend for state of the art optimizations. * What other projects call "Link Time Optimization" Zig does automatically. * For native targets, advanced CPU features are enabled (-march=native), thanks to the fact that Cross-compiling is a first-class use case. * Carefully chosen undefined behavior. For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. This facilitates optimizations that are not available in C. Zig directly exposes a SIMD vector type, making it easy to write portable vectorized code. So the argument is "exact same compiler as C/C++, but more opportunities for optimization thanks to better semantics and better access to native instructions". This seems reasonable on its face, so care to elaborate on the doubt? The arguments for not switching from C are often performance or target related, so a language that purports to be an alternative to C would want to point out that those issues aren't a problem. The reasons to switch away from C are numerous and well documented.

saagarjha 7y ago
> For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. Huh, that's a strange choice. What's the safety story for Zig? Are these always undefined, or is that only in an "unchecked" build?
- AnIdiotOnTheNet 7y ago
  The latter. Zig actually kinda does define this behavior as "`a + b` shall not overflow" and inserts checks in debug and safe builds for it. To get overflow, which zig defines as wrapping overflow, you use a different operator and no check is inserted "`a +% b`". For speed optimized builds, unless you've explicitly told the compiler to insert checks in that scope, it will turn the checks into nops. So, while it is technically correct to say that it has undefined behavior for overflow, the practical reality is quite different.
  - steveklabnik 7y ago
    We do the same thing in Rust, but I think that characterizing this as UB is misleading, personally. We created a new category, "program error", for this, to distinguish from UB proper. I'm not sure if Zig inherited the defined/implementation defined/undefined hierarchy from C and C++ though.
    - fengb 7y ago
      There's a task to rename UB to illegal behavior: https://github.com/ziglang/zig/issues/2402 https://github.com/ziglang/zig/issues/2402 As well as some followups to see if Zig can detect all of these errors: * https://github.com/ziglang/zig/issues/1966 https://github.com/ziglang/zig/issues/1966 * https://github.com/ziglang/zig/issues/2301 https://github.com/ziglang/zig/issues/2301
    - snagglegaggle 7y ago
      Undefined as in undefined by language spec. There are various processor implementations that have different results that are often quite useful. Would you preclude their use?
      - steveklabnik 7y ago
        Right, the key here is that the behavior is defined. That’s why calling it “undefined behavior” is misleading.
        snagglegaggle 7y ago
        It is defined if you want to restrict where your program runs.
        steveklabnik 7y ago
        If something is defined or not is a property of the language specification, as you stated. What you’re now bringing up is something different: should a specification define this behavior, or not? I think you’ve properly identified a trade off, but mid-identified the details. Defining a behavior here does privilege certain architectures, but it doesn’t make it impossible. It means the behavior must be replicated in code on some architectures, which is slower. This is the trade off that Rust (and apparently Zig) are making. This is informed by the architectures that exist, and which ones are wished to support. At this point, two’s compliment is overwhelmingly used, and so the decision was made that defined behavior is worth it. Note the parallel here with POSIX specifying that CHAR_BIT must be set to 8. Notably, the situation here is so overwhelming that even C++ is specifying two’s compliment: C++20 says that signed integers must be. This was recently voted in. I haven’t read the paper recently and I don’t remember if it changes the UB rule here or not, but it does define the representation of integers, a very similar thing that’s the motivation for UB here.

by lkey 7y ago

saagarjha 7y ago

> For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. Huh, that's a strange choice. What's the safety story for Zig? Are these always undefined, or is that only in an "unchecked" build?

AnIdiotOnTheNet 7y ago
The latter. Zig actually kinda does define this behavior as "`a + b` shall not overflow" and inserts checks in debug and safe builds for it. To get overflow, which zig defines as wrapping overflow, you use a different operator and no check is inserted "`a +% b`". For speed optimized builds, unless you've explicitly told the compiler to insert checks in that scope, it will turn the checks into nops. So, while it is technically correct to say that it has undefined behavior for overflow, the practical reality is quite different.
- steveklabnik 7y ago
  We do the same thing in Rust, but I think that characterizing this as UB is misleading, personally. We created a new category, "program error", for this, to distinguish from UB proper. I'm not sure if Zig inherited the defined/implementation defined/undefined hierarchy from C and C++ though.
  - fengb 7y ago
    There's a task to rename UB to illegal behavior: https://github.com/ziglang/zig/issues/2402 https://github.com/ziglang/zig/issues/2402 As well as some followups to see if Zig can detect all of these errors: * https://github.com/ziglang/zig/issues/1966 https://github.com/ziglang/zig/issues/1966 * https://github.com/ziglang/zig/issues/2301 https://github.com/ziglang/zig/issues/2301
  - snagglegaggle 7y ago
    Undefined as in undefined by language spec. There are various processor implementations that have different results that are often quite useful. Would you preclude their use?
    - steveklabnik 7y ago
      Right, the key here is that the behavior is defined. That’s why calling it “undefined behavior” is misleading.
      - snagglegaggle 7y ago
        It is defined if you want to restrict where your program runs.
        steveklabnik 7y ago
        If something is defined or not is a property of the language specification, as you stated. What you’re now bringing up is something different: should a specification define this behavior, or not? I think you’ve properly identified a trade off, but mid-identified the details. Defining a behavior here does privilege certain architectures, but it doesn’t make it impossible. It means the behavior must be replicated in code on some architectures, which is slower. This is the trade off that Rust (and apparently Zig) are making. This is informed by the architectures that exist, and which ones are wished to support. At this point, two’s compliment is overwhelmingly used, and so the decision was made that defined behavior is worth it. Note the parallel here with POSIX specifying that CHAR_BIT must be set to 8. Notably, the situation here is so overwhelming that even C++ is specifying two’s compliment: C++20 says that signed integers must be. This was recently voted in. I haven’t read the paper recently and I don’t remember if it changes the UB rule here or not, but it does define the representation of integers, a very similar thing that’s the motivation for UB here.