1. 42
  1.  

  2. 4

    Interesting points, thanks a lot! Something I hated about Zig (in 0.8.0 actually, just looked at the master doc and it seems they removed this feature) is how they handled global variables.

    In the doc of 0.8.0 (https://ziglang.org/documentation/0.8.0/#Global-Variables), you can see this piece of code:

    const std = @import("std");
    const expect = std.testing.expect;
    
    test "namespaced global variable" {
        try expect(foo() == 1235);
        try expect(foo() == 1236);
    }
    
    fn foo() i32 {
        const S = struct {
            var x: i32 = 1234;
        };
        S.x += 1;
        return S.x;
    }
    

    and at first you can say “oh, the second expect will fail as we create S inside foo, as well as the internal structure and blablabla… so the value of x should be 1234 again when calling a second time the foo function. But no, this code works, as x is considered here as a global variable outside of the foo scope (!!).
    I thought it was a bug at the beginning but the feature was highlighted in the documentation so I guess it was not a bug…

    I am finally glad they removed this in the new master release (https://ziglang.org/documentation/master/#Container-Level-Variables).

    EDIT: As joed pointed just below, the feature still exists under the Static Local Variables header name.
    Still confused by “how to specify the local variable is static?”…

    1. 3

      Looks like a misfeature inherited from C. Sigh.

      1. 2

        That’s still there in master, just under a different heading a bit further down: “static local variables”.

        1. 1

          Oh indeed! Thanks for letting me know :)

      2. 3

        Interesting points !

        I am very curious about if/how Zig will let us deal with error context: I miss them.

        Same goes with “vtbl sugar (interface, protocol, trait)”: I really like them in C# and I wonder what it could look like in Zig without being a pain in the ass to write.

        1. 1

          Same goes with “vtbl sugar (interface, protocol, trait)”: I really like them in C# and I wonder what it could look like in Zig without being a pain in the ass to write.

          Indeed… Generics mechanism is implemented by default and you can use them but interfaces purposes (https://www.nmichaels.org/zig/interfaces.html) but the approach is… not so pleasant I would say.

        2. 2

          These are good points!

          I’ve also found the ‘laziness’ of the compiler sometimes bites. You can define a function, then not use it (perhaps forgotten after some rewriting), and then the compiler will simply ignore it completely, beyond syntax errors. You can have nonsensical stuff in there, like accessing fields that don’t exist, and it’s not an error.

          In general, Zig does some fun things, but I don’t really see why I would choose it over something else, except for its C interop. Completely manual memory management is a lot to ask, when the competition is Rust and C++.

          1. 4

            You can define a function, then not use it (perhaps forgotten after some rewriting), and then the compiler will simply ignore it completely, beyond syntax errors.

            This has changed in the latest builds of master branch, now the compiler is much more strict and will even complain about unused variables. It’s all part of the big rewrite for self-hosted that is progressively being integrated with the current hybrid Zig / C++ compiler.

          2. 2

            Very good writing.

            For me, I wish Zig would take a step towards being Scientific Programming friendlier:

            1. Built In types for Tensors, Matrix and Vectors with respective operations.
            2. Multiple dispatch like in Julia.