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.

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) }`