[mtlynch]

I think this is the post parent is referencing:

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]

It's Zig's equivalent of the newtype idiom: 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]

Ah, thanks! I tried converting that example to Zig:

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]

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]

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]

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