I really don’t agree with the idea that this is functional colouring. Then we have to start talking about function colouring in a whole bunch of new contexts like with Zigs explicit passing of allocator. Or any other parameter that needs to be explicitly passed to use some kind of interface.

I think we should stick to talking about colouring when there is special calling conventions or syntax, which has the consequence of having to write separate libraries/modules for async code and non-async code.

That is the significant problem we have been seeing with many async implementation, and the one which Zig apparently fully solves.

Look, either you move the program counter to a different place in memory (function call) or you push a task into an event loop. Even if you somehow elide all these differences, they're so different under the hood you'll always have to know in some circumstances. It's honestly wild we conflate them at all.

If you want to go down that route, any function that has, or doesn't have, any given resource is colored then.

   fn foo(db: *Db) !void { ... }
   fn bar() !void { ... }

Would you consider `foo` a blue function and `bar` a red function? That doesn't seem particularly helpful to me.

The virality of async await is that once you mark a function async, then you can only call it from another async function, which forces you to mark more functions async, which in turn means that if you want to use blocking I/O APIs then you just can't because it's incompatible with your execution model because by daring to express asynchronicity of operations, you were forcefully opted into stackless coroutines.

That's what Zig solves, and that's what is real function coloring. People have written reimplementations of the same libraries multiple times because of it.

https://github.com/redis/redis-py https://github.com/jonathanslenders/asyncio-redis

Just as an example. Note also how, coincidentally, this duplication of effort resulted in asyncio-redis being semi-abandoned and looking for maintainers. And you have to have both libraries because the asyncio one can't do blocking, and vice versa the other one can't do async.

Would you write two instances of essentially the same library just because one is missing an argument that gives it access to an `Io` interface? No, because you would just pass that extra argument around and nothing else would have to change.

Related discussion (Zig's New Async I/O): https://news.ycombinator.com/item?id=44545949