Re:Resizable Structs in Zig
by atmikemikeb on Saturday July 26, 2025 @06:56PM
(#44697557)
Yeah I think mine is more about being able to provide a `host()` helper function instead of a `.get(.host)` meta function. It is somewhat boilerplate-y. I think it's really a matter of taste haha. Likely yours would be useful regardless if this is done a lot, since it abstracts some of it, if one wants that.
I've entertained further expanding this API to expose a comptime generated struct of pointers. From the Connection use-case detailed in the article, it would look something like this:
pub fn getPtrs(self: Self) struct {
client: *Client,
host: []u8,
read_buffer: []u8,
write_buffer: []u8,
} {
return .{
client: self.get(.client),
host: self.get(.host),
read_buffer: self.get(.read_buffer),
write_buffer: self.get(.write_buffer),
}
}
I haven't done this because I'm not yet convinced it's worth the added complexity
Because the solution outlined in the article stores the lengths alongside the pointer, instead of behind it, there is room for it to work across an ABI (though it currently does not). It's more like a slice in this way.
You could in theory implement your opaque approach using this as a utility to avoid the headache of alignment calculations. For this reason, I think that makes the approach outlined in the article more suitable as a candidate for inclusion in the standard library.