> It would be checked illegal behavior to make an indirect call through a pointer to a restricted function type when the value of that pointer is not in the set of possible callees that were analyzed during compilation.
That's... a pretty nasty trade-off. Object safety in Rust is really annoying for async, and this smells a lot like it. The main difference is that it's vaguely late-bound in a magical way; you might get an unexpected runtime error and - even worse - potentially not have the tools to force the compiler to add a fn to the set of callees.
I still think sans-io at the language level might be the future, but this isn't a complete solution. Maybe we should be simply compiling all fns to state machines (with the Rust polling implementation detail, a sans-io interface could be used to make such functions trivially sync - just do the syscall and return a completed future).
Maybe I'm missing something, but that's still a proposal, which also assumes an implementation for the other proposal you linked and that also doesn't exist yet.
For now I would refrain from commenting on non-existing functionality.
> I still think sans-io at the language level might be the future, but this isn't a complete solution.
I'm not sure what about this is really at the language level (only stackless coroutines appear to require language level support, and it's still unclear if it's really possible to implement them). However I do agree that a sans-io, or at least dependency injection for I/O is a great improvement on the library side, and it's something I'd like to see in Rust too.
> I still think sans-io at the language level might be the future, but this isn't a complete solution. Maybe we should be simply compiling all fns to state machines (with the Rust polling implementation detail, a sans-io interface could be used to make such functions trivially sync - just do the syscall and return a completed future).
Can you be more specific what is missing in sans-io with explicit state machine for static and dynamic analysis would not be a complete solution?
Serializing the state machine sounds excellent for static and dynamic analysis.
I'd guess the debugging infrastructure for optimization passes and run-time debugging are missing or is there more?
So I did a bit of research into how this works in Zig under the hood, in terms of compilation.
First things first, Zig does compile async fns to a state machine: https://github.com/ziglang/zig/issues/23446
The compiler decides at compile time which color to compile the function as (potentially both). That's a neat idea, but... https://github.com/ziglang/zig/issues/23367
> It would be checked illegal behavior to make an indirect call through a pointer to a restricted function type when the value of that pointer is not in the set of possible callees that were analyzed during compilation.
That's... a pretty nasty trade-off. Object safety in Rust is really annoying for async, and this smells a lot like it. The main difference is that it's vaguely late-bound in a magical way; you might get an unexpected runtime error and - even worse - potentially not have the tools to force the compiler to add a fn to the set of callees.
I still think sans-io at the language level might be the future, but this isn't a complete solution. Maybe we should be simply compiling all fns to state machines (with the Rust polling implementation detail, a sans-io interface could be used to make such functions trivially sync - just do the syscall and return a completed future).