[dnautics]

something that I don't understand about the actual API:

I maintain the zigler library, and one thing that was useful about the old async "colored-but-not-really" functions was that they implicitly tolerate having internal suspend points (detail: https://www.youtube.com/watch?v=lDfjdGva3NE&t=1819s) -- I'm not sure if having IO be a passed parameter will still let me do that? Can users build their own functions with yield points? And will you be able to jump out of the frame of a function and give control back to the executor, to let it resume later?

[AndyKelley]

Hi Isaac, good to (virtually) see you.

As you're aware, that feature of the language ("stackless coroutines", "generators", "rewriting function logic into a state machine") was regressed. At first, this new IO interface won't have that capability.

However, as a followup issue, I'd like to reintroduce it, potentially in more low-level manner, for use inside IO implementations. Combined with restricted function pointers, this will allow functions that can suspend to pass through runtime-known function pointer boundaries - something that was terribly clunky before to the point that it compromised the entire design. This means that, again, the same IO interface usage code will be able to be reused, including when the implementation uses suspend points, and the automatic calling convention rewriting will be able to propagate through the interface into the usage code.

The issue to track is: https://github.com/ziglang/zig/issues/23446

I'll add that I'm still keen on the previous suspend/resume keywords and semantics as a solution to this issue.

[dnautics]

thanks! I would have asked on stream but I'm in a bit of a different timezone than usual so my ability to track livestream times competently has regressed.

As an aside, do you think in the near future there will be a "guide to building a compiler backend" either in-project or by the community?

[AndyKelley]

I'm not aware of any such effort. The only thing of relevance I have to share on the topic is the new Legalize pass which can ease the job of contributing a backend, because it restricts the subset of AIR instructions that a backend must lower based on a set of features the backend opts into. For example, it can scalarize all the vectors so the backend does not have to be vector-aware.