I agree on the last point of the lack of composition here.
While it's true that writers need to be aware of buffering to make use of fancy syscalls, implementing that should be an option, but not a requirement.
Naively this would mean implementing one of two APIs in an interface, which ruins the direct peformance. So I see why the choice was made, but I still hope for something better.
It's probably not possible with zig's current capabilities, but I would ideally like to see a solution that:
- Allows implementations to know at comptime what the interface actually implements and optimize for that (is buffering supported? Can you get access to the buffer inplace for zero copy?).
- For the generic version (which is in the vtable), choose one of the methods and wrap it (at comptime).
There's so many directions to take Zig into (more types? more metaprogramming? closer to metal?) so it's always interesting to see new developments!
While it's true that writers need to be aware of buffering to make use of fancy syscalls, implementing that should be an option, but not a requirement.
Naively this would mean implementing one of two APIs in an interface, which ruins the direct peformance. So I see why the choice was made, but I still hope for something better.
It's probably not possible with zig's current capabilities, but I would ideally like to see a solution that:
- Allows implementations to know at comptime what the interface actually implements and optimize for that (is buffering supported? Can you get access to the buffer inplace for zero copy?).
- For the generic version (which is in the vtable), choose one of the methods and wrap it (at comptime).
There's so many directions to take Zig into (more types? more metaprogramming? closer to metal?) so it's always interesting to see new developments!