This thread, and especially this post, within, do a great job of fleshing out the differences between Io and Allocator patterns, in which we regularly use an &io.interface and, somewhat seemingly-similarly (to higher-level code), we use an allocator.allocator(). But I have a stupid follow-up question. I know there’s work planned to take away the footgun of forgetting the ‘&’ when referencing an io interface, but I’m curious about the reasons to not make an interface() function, instead, which returns the reference (and thus avoids accidental copies)… then the “usage symmetry” between allocator.allocator() and io.interface() would… maybe?… “feel” like intentional consistency? (though that may be a fallacious goal, of course.) Perhaps overhead is a consideration… are there others?
2 Likes
Please don’t refer to reader and writer as Io interface, as the Io interface is a separate (WIP on master) thing.
because that is just pushing the burden of safety onto the programmer, while zig does expect you to know what you are doing, it does not assume you won’t make mistakes cough unlike c cough
I would like to keep the asymmetry that currently exists, as they are different styles of interface. It serves as a learning opportunity for those that are unfamiliar with the different styles.
4 Likes