> > First: PHP having native async support would be a huge step forward for > the language. It's really exciting to see how this proposal develops. > > Thank you for the kind words, it was awesome to read.
I wonder if there are ways it can be split into smaller pieces, so that > we don't overlook details in one part because our focus is drawn to another. I can suggest the following workflow: 1. *Approval of the core concept*: Changes affecting the language core. 2. *Decision on the low-level API*: Async\wait + Resume + microtask. Should it be exposed to PHP developers or not? (I don’t have a definitive answer). This is a crucial point that impacts 30-40% of the code. If the decision is made to hide this API, the code will need to be adjusted. Next, the RFC can be split into two parts: - *Low-level*: Basic PHP primitive functions + C API - *High-level*: Future, await, Channel, and maybe Pool. So the process would be: 3. Approval of the *Low-level RFC* 4. Approval of the *High-level RFC*. Step 4 depends on Step 3 in terms of implementation but is almost independent in terms of *semantics*. This means it can be discussed separately and more freely. Additionally, the *Low-level API* can be released independently, allowing PHP extensions to adopt concurrency earlier. As for function names, I really hope for your support in this matter because it's far from trivial. Thanks, Ed.
