News for hackers. Stuff that matters.
Re:Rust’s async isn’t colored by dnautics on Thursday March 11, 2021 @10:47AM (#26425239)
> Allocating functions are red, zero-alloc are blue and you can't call a red function from a blue one

This is not entirely correct analogy. You can embed your allocator inside one of the parameters, too, as a strategy (perhaps a certain type of "object" should carry it's allocator with it).

Then uncolored generic functions could operate on allocator-bound and allocator-unbound "objects" alike, even if say the generic function calls a "object method" that performs an allocation in one case but not the other.... You just have to be careful about how to handle errors.

There is no equivalent for async.

If you were going to be serious about function coloring in zig, the place where there is function coloring is functions with error return values but that's actually a reasonable place to have function coloring, and still, it's easy to build seams in both directions, so a red function can call a blue function, and a blue function can call a red function pretty easily.

Re:Rust’s async isn’t colored by littlestymaar on Thursday March 11, 2021 @10:55AM (#26425349)
> There is no equivalent for async.

Sure there is, a symmetrical one: you can embed the Future/Promise inside one of the return value of you sync function. Both work, but both are equally hackish.

> If you were going to be serious about function coloring in zig, the place where there is function coloring is functions with error return values

I actually address it a bit below.

Re:Rust’s async isn’t colored by dnautics on Thursday March 11, 2021 @11:32PM (#26432233)
No, your understanding is not correct. It's not "hackish" to embed your allocator in your object, sometimes it is the correct, domain driven choice to make. I know it's done somewhere in zig stdlib (parser, iirc).