I would describe this approach as 'intrusive' - you're storing the lengths of the arrays behind the pointer, enforcing a certain layout of the memory being allocated.

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.

▲ atmikemikeb 3 days ago | parent [-]

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.

	▲	rvrb 3 days ago \| parent [-]
		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