[IDEA] Native async/await syntax on top of Fibers

Hi internals, I'd like to gauge interest in adding native async/await syntax to PHP, built on top of the Fiber implementation we've had since 8.1. Fibers made it possible to write concurrent code without "function colouring", but in practice everyone still picks a userland library (Amp, ReactPHP, Revolt) together with its own Promise/Future type, and the code doesn't say directly what it means. The idea is to give the engine a small, standard vocabulary for this: async function fetch(string $name, float $secs): string { await Async\delay($secs); return "$name done"; } $a = fetch("a", 0.2); // starts right away, returns Async\Future $b = fetch("b", 0.2); echo await $a, await $b; // ~0.2s total, not 0.4s Proposed semantics, in short: - async can be applied to functions, methods, closures and arrow functions. Calling one runs its body in a new Fiber and returns an Async\Future. The task starts eagerly and runs until it awaits a Future that isn't complete yet. - await <expr> inside a task suspends that task. Outside a task (at the top level, or in a plain Fiber) it drives a small scheduler until the Future completes. It returns the value or rethrows the exception. - async is a contextual keyword: it is only a keyword when followed by function or fn, so existing userland async() functions keep working. await would become a reserved keyword, though it remains usable as a method, constant or property name. - Tasks still pending at shutdown are destroyed the same way suspended Fibers are, so their finally blocks run. Deadlocks throw an Error instead of hanging. - A minimal runtime API: final class Async\Future, Async\async(), Async\wait() (the function form of await), Async\delay() and Async\suspend(). I have a working prototype. Both constructs are desugared in the parser into calls to the runtime functions, so there are no new opcodes and no VM changes: https://github.com/php/php-src/pull/24623 It comes with tests and passes the existing test suite on a debug build (macOS arm64, NTS). I haven't tried it on Windows or ZTS yet. Questions I'd especially like feedback on: 1. Is reserving await an acceptable BC break? Unqualified functions named await() would break; namespaced calls such as Amp\Future\await() would not. 2. How should this relate to the True Async RFC? Should syntax like this be layered on top of that work rather than proposed separately? 3. What should I/O integration look like? The prototype only supports timers and cooperative yielding. Real-world usefulness depends on an event-loop or reactor story for streams and sockets. 4. Known rough edges in the desugaring approach: func_get_args() inside an async body returns [], stack traces show an extra {closure} frame, and reflection reports the return type as Async\Future. Are these acceptable, or is a dedicated engine-level implementation preferred? If there is interest, I'm happy to turn this into a proper RFC. Thanks, Abbas Al-Khateeb