3 ms·

Totally off-topic: I installed Zig on Saturday afternoon and by the evening I had my first program do some useful stuff, on Sunday I added some C code, then add

Totally off-topic: I installed Zig on Saturday afternoon and by the evening I had my first program do some useful stuff, on Sunday I added some C code, then added some tests and by Sunday evening I had a pure Zig project again (and afterwards learned that translate-to-zig is a thing). I gotta say I'm very impressed with Zig and partial evaluation is just such a nice, mentally simple technique for generics and lots of other things. The syntax is pretty nice, too, though the prefix-[] are kinda weird (just way too used to C/C++'s postfix array notation) and ranged loops are somewhat awkward. The @ naming for builtins confused me for a bit because I thought the @ itself was syntax. And array literals are kinda weird sometimes though I've seen that apparently in 0.9 "&[_][]const u8{ "-std=c99", "-O3" }" can just be written as ".{ "-std=c99", "-O3" }". And I was kinda surprised about array types in function signatures being implicitly const, I think they're like that to make array types behave mostly like value types while only passing a pointer?

dnautics 5y ago
> the prefix-[] are kinda weird (just way too used to C/C++'s postfix array notation) I think over time the C/C++ way is going to go the way of the dodo; IIRC, rust and go both use the prefix-[]. It creates a clear, unambiguous way of defining the type (no "spiral typing" jokes for the modern languages).
- nyanpasu64 5y ago
  I wish Rust used prefix &[]i32 for a slice, and [5][2]i32 for a 5x2 array. Instead it uses &[i32] for a slice, and [[i32; 2]; 5] for a 5x2 array. Reading types backwards is alive and well.
  - dnautics 5y ago
    eh, the type surrounded by the [] "operator" is equally unambiguous as prefix-[], so it's not the worst.
  - mmastrac 5y ago
    I prefer the unambiguous nesting of Rust's style. I can never remember the array shape when array bounds are listed in either prefix or postfix style. It's a tiny bit of extra typing that ensures that my understanding of the code is always 100% correct.
    - nyanpasu64 5y ago
      I find Rust's array style more confusing than prefix, since prefix matches the order you index into the arrays (arr: [5][2]i32 can be validly indexed as arr[<5][<2]), and Rust's style is written backwards from how you index the array. Can you clarify how you find Rust unambiguous?
      - mmastrac 5y ago
        It's just obvious to me that it works the correct way by way of elimination of alternative parsing. The example below can be unwrapped mentally and unambiguously as "an array of 5 items of (an array of 2 items of i32)". Indexing into the array is not backwards: the outer array is deref'd first, giving you one of those five items which has length two. fn main() { let mut a: [[i32; 2]; 5] = [[0,0],[0,0],[0,0],[0,0],[0,0]]; println!("{:?}", a[0]); } Note that the Rust array declarations are also homologous to other types in the ecosystem, such as nested Option types or nested collections (eg: Option<Option<T>> or List<List<T>>). Contrast w/the C version, where it's obvious to a skilled C programmer but you need to remember to read the bounds from right to left to determine the memory layout (ie: an array of 5 arrays of two elements each): int main() { int i[5][2] = {{1,2},{3,4}, /*...*/}; printf("%ld\n", sizeof(i[0])/sizeof(int)); return 0; } In this case you are required to mentally combine the type on the left of the variable with the bounds on the right of the variable to parse a type declaration in your head that eventually looks like the Rust version: (int[2])[5] I've been doing a lot of professional C work lately so it's currently "swapped in", but I find that any time I pick C up after spending time away I find it ambiguous and I have to reason through the ordering of the declarations. Obviously this is all IMHO and YMMV, but this developer does find it significantly easier to unambiguously parse Rust types.
        deleted 5y ago
Spex_guy 5y ago
Your instinct is right about array types, semantically in Zig they are passed by value. Parameter values are always const though, which allows the compiler to sometimes use pass-by-const-ref to avoid copying large pieces of data. Since arrays are proper value types, we can also make strongly typed pointers to them, like `*[3][4]u32`.

dnautics 5y ago

> the prefix-[] are kinda weird (just way too used to C/C++'s postfix array notation) I think over time the C/C++ way is going to go the way of the dodo; IIRC, rust and go both use the prefix-[]. It creates a clear, unambiguous way of defining the type (no "spiral typing" jokes for the modern languages).

nyanpasu64 5y ago
I wish Rust used prefix &[]i32 for a slice, and [5][2]i32 for a 5x2 array. Instead it uses &[i32] for a slice, and [[i32; 2]; 5] for a 5x2 array. Reading types backwards is alive and well.
- dnautics 5y ago
  eh, the type surrounded by the [] "operator" is equally unambiguous as prefix-[], so it's not the worst.
- mmastrac 5y ago
  I prefer the unambiguous nesting of Rust's style. I can never remember the array shape when array bounds are listed in either prefix or postfix style. It's a tiny bit of extra typing that ensures that my understanding of the code is always 100% correct.
  - nyanpasu64 5y ago
    I find Rust's array style more confusing than prefix, since prefix matches the order you index into the arrays (arr: [5][2]i32 can be validly indexed as arr[<5][<2]), and Rust's style is written backwards from how you index the array. Can you clarify how you find Rust unambiguous?
    - mmastrac 5y ago
      It's just obvious to me that it works the correct way by way of elimination of alternative parsing. The example below can be unwrapped mentally and unambiguously as "an array of 5 items of (an array of 2 items of i32)". Indexing into the array is not backwards: the outer array is deref'd first, giving you one of those five items which has length two. fn main() { let mut a: [[i32; 2]; 5] = [[0,0],[0,0],[0,0],[0,0],[0,0]]; println!("{:?}", a[0]); } Note that the Rust array declarations are also homologous to other types in the ecosystem, such as nested Option types or nested collections (eg: Option<Option<T>> or List<List<T>>). Contrast w/the C version, where it's obvious to a skilled C programmer but you need to remember to read the bounds from right to left to determine the memory layout (ie: an array of 5 arrays of two elements each): int main() { int i[5][2] = {{1,2},{3,4}, /*...*/}; printf("%ld\n", sizeof(i[0])/sizeof(int)); return 0; } In this case you are required to mentally combine the type on the left of the variable with the bounds on the right of the variable to parse a type declaration in your head that eventually looks like the Rust version: (int[2])[5] I've been doing a lot of professional C work lately so it's currently "swapped in", but I find that any time I pick C up after spending time away I find it ambiguous and I have to reason through the ordering of the declarations. Obviously this is all IMHO and YMMV, but this developer does find it significantly easier to unambiguously parse Rust types.
      - deleted 5y ago

Spex_guy 5y ago

Your instinct is right about array types, semantically in Zig they are passed by value. Parameter values are always const though, which allows the compiler to sometimes use pass-by-const-ref to avoid copying large pieces of data. Since arrays are proper value types, we can also make strongly typed pointers to them, like `*[3][4]u32`.