Hello Edmond,
On 19.11.2025 13:35:13, Edmond Dantes wrote:
Hello all
According to all previous discussions, version 1.6 of this RFC has
been prepared and is now being submitted for a vote:
Voting Page: PHP: rfc:true_async:voting
RFC PHP: rfc:true_async
The vote officially starts tomorrow, as previously announced.
This comes a bit of sudden. For sure, you respected the minimum discussion period, though there was still active discussion just yesterday and the few days before.
I was also planning to give the now shortened variant of the RFC a thorough read and read the discussions around it.
Others seem to also indicate that there were still a couple open points for discussion - thus I would advise you to cancel the vote and discuss these points first, then go ahead with a vote again a week later.
My own thoughts on the RFC (from just reading the RFC in depth, without considering prior conversations now):
I agree with the choices of separating Fiber and Coroutine, but I disagree that there's a fundamental problem with allowing Fibers in Coroutines. A Fiber is essentially just a stackful generator, from a very-high-level perspective. You allow generators to be used with Coroutines. There should be no fundamental reason this isn't possible. It just might require some refactoring of the code to manage it properly (i.e. just like you cannot continue a generator which is currently active, but suspended in a fiber, you should not be able to resume a fiber which is currently active, but suspended in a coroutine).
Cancellation is not an Error - Errors are generally for programmer errors, not for exceptional behaviour. There might be an argument for making Cancellation a top-level item below Throwable, because it's really special. But definitely not Error. (And if you do, the RFC should note a small policy amendment too.)
I'm not particularly fond of the FutureLike name. Is there a reason why it isn't simply called "Future"?
I know that in an earlier iteration there was a Future class. But Future is only the promise of a future value. It's the callee API.
Callers can return specific implementations of Future, like "new Async\Completed(true)", "new Async\Completable" (which has a $future object as part of its API, which then can be awaited on), "new Async\Failed($someException)".
A Coroutine should not only offer the current suspend location as API, but the full stacktrace too. (Like ReflectionFiber does.)
Async\suspend() should maybe be called Async\yield() - as in yielding control back to the scheduler. Suspension is the observable side-effect of yielding or awaiting. But you don't actually suspend a coroutine, the action of suspending is done by the scheduler. [This also would match terminology used by the linux kernel for example, which calls it sched_yield(). I think it's misnamed on Fiber.] I don't feel strongly about that though.
I find it confusing that an "await" operation does not accept Awaitable as its primary argument, but FutureLike per its signature. Why is that? The doc for Awaitable says that there can be await calls on those. But Async\await can't await it? What exactly is an Awaitable then? Would it essentially be the equivalent of an iterable Future (as in: can be awaited multiple times)?
Minor nit: Coroutine::onFinally() could be just called Coroutine->finally().
Thank you for working on this,
Bob