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: https://wiki.php.net/rfc/true_async/voting
RFC https://wiki.php.net/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
