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.