>
> 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.