4 ms·

I think this is the post parent is referencing: https://ziglang.org/devlog/2024/#2024-11-04 https://ziglang.org/devlog/2024/#2024-11-04 It seems like an inter

I think this is the post parent is referencing: https://ziglang.org/devlog/2024/#2024-11-04 https://ziglang.org/devlog/2024/#2024-11-04 It seems like an interesting idea, but I wish Andrew spent more time fleshing it out with complete examples. I can't tell if the _ characters are eliding values or if that's literally what's in his code.

defen 2y ago
It's Zig's equivalent of the newtype idiom: https://doc.rust-lang.org/rust-by-example/generics/new_types.html https://doc.rust-lang.org/rust-by-example/generics/new_types... for integers. The underscores mean that it's a non-exhaustive enum. An exhaustive enum is where you list all the names of the possible enum values, and other values are illegal. A non-exhaustive enum means any value in the underlying storage is allowed. So at root this code is creating a bunch of new integer types which are all backed by u32 but which can't be directly assigned or compared to each other. That means you can't accidentally pass a SectionIndex into a function expecting an ObjectFunctionImportIndex, which would be impossible to do if those functions just took raw u32's.
- mtlynch 2y ago
  Ah, thanks! I tried converting that example to Zig: https://tars.run/t3eInpPFAgc https://tars.run/t3eInpPFAgc Is that the idea? You can do the same thing wrapping integers with structs, but enum makes it slightly more concise?
  - ImprobableTruth 2y ago
    Yes, that's how it works. I think in Zig for new types you'd use enums for ints and packed structs for more complex types.
fallingsquirrel 2y ago
It's an interesting pattern, but it's a shame there's no way to efficiently use one of those OptionalXIndex with zig's actual null syntax, `?` and `orelse` and etc. It would be smoother if you could constraint the nonexhaustive range, and let the compiler use an unused value as the niche for null. Maybe something like `enum(u32) { _ = 1...std.math.maxInt(u32) }`
- samatman 2y ago
  There's an issue tracking that: https://github.com/ziglang/zig/issues/3806 https://github.com/ziglang/zig/issues/3806

defen 2y ago

It's Zig's equivalent of the newtype idiom: https://doc.rust-lang.org/rust-by-example/generics/new_types.html https://doc.rust-lang.org/rust-by-example/generics/new_types... for integers. The underscores mean that it's a non-exhaustive enum. An exhaustive enum is where you list all the names of the possible enum values, and other values are illegal. A non-exhaustive enum means any value in the underlying storage is allowed. So at root this code is creating a bunch of new integer types which are all backed by u32 but which can't be directly assigned or compared to each other. That means you can't accidentally pass a SectionIndex into a function expecting an ObjectFunctionImportIndex, which would be impossible to do if those functions just took raw u32's.

mtlynch 2y ago
Ah, thanks! I tried converting that example to Zig: https://tars.run/t3eInpPFAgc https://tars.run/t3eInpPFAgc Is that the idea? You can do the same thing wrapping integers with structs, but enum makes it slightly more concise?
- ImprobableTruth 2y ago
  Yes, that's how it works. I think in Zig for new types you'd use enums for ints and packed structs for more complex types.

fallingsquirrel 2y ago

It's an interesting pattern, but it's a shame there's no way to efficiently use one of those OptionalXIndex with zig's actual null syntax, `?` and `orelse` and etc. It would be smoother if you could constraint the nonexhaustive range, and let the compiler use an unused value as the niche for null. Maybe something like `enum(u32) { _ = 1...std.math.maxInt(u32) }`

samatman 2y ago
There's an issue tracking that: https://github.com/ziglang/zig/issues/3806 https://github.com/ziglang/zig/issues/3806