Zig's new I/O: function coloring is inevitable?

Post by woodruffw » Mon, Jul 14, 2025, 4:20 AM UTC

throwawaymaths wrote: post #28

woodruffw wrote: post #21

Earlier quoted context omitted.

This is effectively a special calling convention: Zig expects you to pass in a "token" object that communicates a kind of effect (I/O in this case). No token, no effect (modulo a soundness hole). This is not a new pattern, and I think it's a pretty good one (and is arguably more ergonomic and general than syntax-level effects). But it's quintessential function coloring.

> Zig expects you to pass It does no such thing. you could pass a function a vtable and the vtable could have one implementation that calls an io stashed in the parent of the vtable, and a different vtable that doesnt and the function calling the vtable would be none the wiser. what is the color of the function that took the vtable? this is not just academic; it would be for example the basis for mocked integration t…

Post by 0x457 » Mon, Jul 14, 2025, 4:27 AM UTC

koiueo wrote: post #27

nextaccountic wrote: post #22

Earlier quoted context omitted.

Yeah, parameter passing can be seen as some kind of effect (like the Reader monad in Haskell). Passing parameters down the call stack is viral just like function coloring (if you need to do i/o and thus need to receive an io parameter, then your caller must receive an io parameter too, recursively; this is analogous to adding a keyword async in front of your function, and to its callers recursively). The solution is…

> Passing parameters down the call stack is viral It's in a different league comparing to async-await abomination. For one, you can store parameter on a struct thus working around the "virality" on a call site.

Post by vips7L » Mon, Jul 14, 2025, 5:10 AM UTC

koiueo wrote: post #26

If we apply your logic, then every mainstream language has the coloring problem with not just two, but a multitude of colors. // OMG we can't call this without passing the service // This function is people-colored public Person findPersonByName(PeopleService service, String name) { // OMG we can't find without the service service.find(name) } EDIT: formatting

Post by koiueo » Mon, Jul 14, 2025, 5:28 AM UTC

vips7L wrote: post #35

koiueo wrote: post #26

If we apply your logic, then every mainstream language has the coloring problem with not just two, but a multitude of colors. // OMG we can't call this without passing the service // This function is people-colored public Person findPersonByName(PeopleService service, String name) { // OMG we can't find without the service service.find(name) } EDIT: formatting

This is off topic. But I really hate “services”. They always are just some random collection of functions and aren’t a real object at all.

Post by woodruffw » Mon, Jul 14, 2025, 5:38 AM UTC

koiueo wrote: post #36

0x457 wrote: post #33

Earlier quoted context omitted.

Huh? You have the following call stack (top to bottom): a -> b -> c -> d Function "d" does IO, so a, b and c need to pass that IO down. It's the same as with async in terms of virality. If I understood correctly, the main benefit here is that you don't have to dance around "can I call this function or is it going to block async runtime reactor?" I would pick async/await style over this because (I think) extra functio…

const Greeter = struct { io: std.Io, pub fn greet(self: Greeter, msg: []const u8) !void { var stdout_writer = self.io.stdout.writer(); try stdout_writer.writeAll(msg); } } Greeter.greet("Look ma, no coloring")