Zig 0.5.0 Release Notes

Post by steveklabnik » Mon, Sep 30, 2019, 7:19 PM UTC

AnIdiotOnTheNet wrote: post #46

saagarjha wrote: post #42

Earlier quoted context omitted.

> 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?

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 te…

Post by AnIdiotOnTheNet » Mon, Sep 30, 2019, 7:21 PM UTC

renox wrote: post #50

rhodysurf wrote: post #31

Earlier quoted context omitted.

They got rid of the % operator for error propagation for one.

That's funny; one selling point of rust is the easy propagation of errors thanks to the '?' but zig removed the % which was the equivalent I think

Post by fengb » Mon, Sep 30, 2019, 7:40 PM UTC

steveklabnik wrote: post #51

AnIdiotOnTheNet wrote: post #46

Earlier quoted context omitted.

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 te…

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.

Post by FpUser » Mon, Sep 30, 2019, 8:31 PM UTC

    function xxx()

    fn xxx()

Post by Bootvis » Mon, Sep 30, 2019, 8:45 PM UTC

0xdead wrote: post #54

trulyrandom wrote: post #24

Earlier quoted context omitted.

Whether the claim hold up or not. If you developed a language that's faster than C, would you not advertise that as a feature?

I would, first of all, call bullshit on this claim. A language can't be "faster than C". Comparing a good implementation with a bad C implementation is where these claims come from.