Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129006
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
In-Reply-To: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
Date: Thu, 30 Oct 2025 10:32:43 -0300
Message-ID: <CADK1yXLLn1Sjp2ByxSJWBFhh+3dkTuFPtF7Cxrwz8TMzAZ-MZA@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 5
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cc09d60642604a1e"
From: deleugyn@gmail.com (Deleu)

--000000000000cc09d60642604a1e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Edmond!

On Thu, Oct 30, 2025 at 5:22=E2=80=AFAM Edmond Dantes <edmond.ht@gmail.com>=
 wrote:

> Hi
>
> 1.5 RFC:
> https://wiki.php.net/rfc/true_async
>
> Here=E2=80=99s the fifth version of the RFC with the updates made after t=
he
> 1.4 discussion.
>
> Starting from 2025-11-03, there will be a two-week discussion period.
>
> **Changelog:**
>
> * Added FutureLike interface methods: cancel(), isCompleted(),
> isCancelled()
> * Renamed Coroutine::isFinished() to Coroutine::isCompleted()
> * Clarified exit/die behavior: always triggers Graceful Shutdown mode
> regardless of where called
> * Added rationale for =E2=80=9CCancellable by design=E2=80=9D policy: exp=
lains why
> default cancellability reduces code complexity for read-heavy PHP
> workloads
> * RFC structure improvements: reorganized Cancellation section with
> proper subsections hierarchy
> * Moved =E2=80=9CCoroutine lifetime=E2=80=9D as subsection under Coroutin=
e section
> * Extended glossary with Awaitable, Suspension, Graceful Shutdown, and
> Deadlock terms
> * Introduced FutureLike interface with single-assignment semantics and
> changed await() signature to accept FutureLike instead of Awaitable
> for type safety
> * Split RFC: Moved Scope and structured concurrency functionality to
> separate Scope RFC. Base RFC now focuses on core async primitives
> (coroutines, await, cancellation)
>
> I decided not to wait until Monday and made the changes today. If
> anyone has read version 1.4 and has comments on it, they=E2=80=99re still
> relevant.
>
> The Scope API has been moved to a separate RFC:
> https://wiki.php.net/rfc/true_async_scope
>
> ----
> Best Regards, Ed
>

Thanks for the RFC update! I've been trying to read and understand this RFC
since its earlier versions and I can definitely feel it getting easier to
digest, which I can only assume it's a good thing for RFC voters - it's
easier to vote No because something is too complex / too hard to understand=
.

One minor question: is this section
https://wiki.php.net/rfc/true_async#awaiting_a_result_with_cancellation
named wrongly? I'm not sure how this snippet of code relates to
cancellation.

Onto more important things. In regards to the change of Awaitable vs
FutureLike, my understanding of the discussion is that on the
implementation side it was asked about whether an Awaitable object should
be awaited in a loop (consumed until completion) or if it should be awaited
only once, which also raised the question about idempotency and whether an
object is awaitable more than once. While the change makes the type-system
somewhat more explicit in regards to how await() is meant for a single-shot
Awaitable object (named FutureLike), it does mean the implementation of
things like awaitAll(Awaitable[] $awaitables) is no longer a simple loop to
await every item in the array.

My questions are:
- What's the difference between Multishot Awaitables and Generators?
- If await() is hardened to FutureLike only, doesn't this mean that
multishot awaitables are not really capable of being awaited anymore?
Doesn't this mean that the Awaitable interface becomes out-of-sync with the
await() function and it stops making sense?
- Shouldn't FutureLike be Awaitable and what has been described as
Multishot awaitables should actually be generators / array of / list of
Awaitables?

In regards to Cancellable by Design. In the current state of PHP, we can
assume that if a function used to throw an Exception and a future version
stops throwing said exception it is not considered a BC Break. Of course,
throwing a *different exception* not part of the hierarchy is a BC break.
But when an exception signals "I cannot handle this" and a future version
becomes capable of handling it, that in essence is a feature/enhancement
and not treated as a BC break. With "Cancellation by Design" we are
expected that every coroutine be cancellable and that we must write try /
catch to design for cancellation. This seems to open up a different
development flow where catch blocks can be fundamentally part of the BC
promise. One possible alternative would be e.g. await(Awaitable $awaitable,
Closure $cancellation) where the cancellation of a coroutine would trigger
the specified Closure. Now, I don't want to dive too much into the
trade-offs of these options, what I want is to spark the idea that there
may be multiple ways to design cancellable coroutines. When I consider
that, plus the added fact that the RFC is very dense, extensive and hard to
digest, wouldn't it be best to postpone coroutine cancellations altogether?
The RFC itself states:

>  [...] read operations (database queries, API calls, file reads) are
typically as frequent as=E2=80=94or even more frequent than=E2=80=94write o=
perations. Since
read operations generally don't modify state, they're inherently safe to
cancel without risking data corruption.

which not only I agree with, but also want us to focus on this very fact.
What if the first version of Async PHP provides userland with the ability
to trigger coroutines for reading purposes only? We will not forbid/prevent
anybody from shooting themselves if they want to, but we can still clearly
state the design principle that Async PHP is meant to spawn coroutines
cancellable by design. There will not be any coroutine markers in the
future nor there will be assumptions that coroutines written for the 1st
version of Async PHP must not be cancellable. The assumption is that the
first version of Async PHP should be treated as a way to perform read
operations only and a future RFC / enhancement will bring cancellation
capabilities (be it Closure, Try / Catch, what have you). My reasoning is
that this would further reduce the scope of the RFC while still introducing
real life useful async components to PHP, even if at a limited capacity. It
gives voters less concepts to understand, digest, agree on and approve and
it extends the opportunity to focus on specific deep aspects of Async PHP
in chunks and throughout different stages.

--=20
Marco Deleu

--000000000000cc09d60642604a1e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Edmond!</div><br><div class=3D"gmail_q=
uote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, O=
ct 30, 2025 at 5:22=E2=80=AFAM Edmond Dantes &lt;<a href=3D"mailto:edmond.h=
t@gmail.com">edmond.ht@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Hi<br>
<br>
1.5 RFC:<br>
<a href=3D"https://wiki.php.net/rfc/true_async" rel=3D"noreferrer" target=
=3D"_blank">https://wiki.php.net/rfc/true_async</a><br>
<br>
Here=E2=80=99s the fifth version of the RFC with the updates made after the=
<br>
1.4 discussion.<br>
<br>
Starting from 2025-11-03, there will be a two-week discussion period.<br>
<br>
**Changelog:**<br>
<br>
* Added FutureLike interface methods: cancel(), isCompleted(), isCancelled(=
)<br>
* Renamed Coroutine::isFinished() to Coroutine::isCompleted()<br>
* Clarified exit/die behavior: always triggers Graceful Shutdown mode<br>
regardless of where called<br>
* Added rationale for =E2=80=9CCancellable by design=E2=80=9D policy: expla=
ins why<br>
default cancellability reduces code complexity for read-heavy PHP<br>
workloads<br>
* RFC structure improvements: reorganized Cancellation section with<br>
proper subsections hierarchy<br>
* Moved =E2=80=9CCoroutine lifetime=E2=80=9D as subsection under Coroutine =
section<br>
* Extended glossary with Awaitable, Suspension, Graceful Shutdown, and<br>
Deadlock terms<br>
* Introduced FutureLike interface with single-assignment semantics and<br>
changed await() signature to accept FutureLike instead of Awaitable<br>
for type safety<br>
* Split RFC: Moved Scope and structured concurrency functionality to<br>
separate Scope RFC. Base RFC now focuses on core async primitives<br>
(coroutines, await, cancellation)<br>
<br>
I decided not to wait until Monday and made the changes today. If<br>
anyone has read version 1.4 and has comments on it, they=E2=80=99re still<b=
r>
relevant.<br>
<br>
The Scope API has been moved to a separate RFC:<br>
<a href=3D"https://wiki.php.net/rfc/true_async_scope" rel=3D"noreferrer" ta=
rget=3D"_blank">https://wiki.php.net/rfc/true_async_scope</a><br>
<br>
----<br>
Best Regards, Ed<br>
</blockquote></div><div><br clear=3D"all"></div><div>Thanks for the RFC upd=
ate! I&#39;ve been trying to read and understand this RFC since its earlier=
 versions and I can definitely feel it getting easier to digest, which I ca=
n only assume it&#39;s a good thing for RFC voters - it&#39;s easier to vot=
e No because something is too complex / too hard to understand.</div><div><=
br></div><div>One minor question: is this section=C2=A0<a href=3D"https://w=
iki.php.net/rfc/true_async#awaiting_a_result_with_cancellation">https://wik=
i.php.net/rfc/true_async#awaiting_a_result_with_cancellation</a> named wron=
gly?=C2=A0I&#39;m not sure how this snippet of code relates to cancellation=
.</div><div><br></div><div>Onto more important things. In regards to the ch=
ange of Awaitable vs FutureLike, my understanding of the discussion is that=
 on the implementation side it was asked about whether an Awaitable object =
should be awaited in a loop (consumed until completion) or if it should be =
awaited only once, which also raised the question about idempotency and whe=
ther an object is awaitable more than once. While the change makes the type=
-system somewhat more explicit in regards to how await() is meant for a sin=
gle-shot Awaitable object (named FutureLike), it does mean the implementati=
on of things like awaitAll(Awaitable[] $awaitables) is no longer a simple l=
oop to await every item in the array.</div><div><br></div><div>My questions=
 are:=C2=A0</div><div>- What&#39;s the difference between Multishot Awaitab=
les and Generators?</div><div>- If await() is hardened to FutureLike only, =
doesn&#39;t this mean that multishot awaitables are not really capable of b=
eing awaited anymore? Doesn&#39;t this mean that the Awaitable interface be=
comes out-of-sync with the await() function and it stops making sense?</div=
><div>- Shouldn&#39;t FutureLike be Awaitable and what has been described a=
s Multishot awaitables should actually be generators / array of / list of A=
waitables?</div><div><br></div><div>In regards to Cancellable by Design. In=
 the current state of PHP, we can assume that if a function used to throw a=
n Exception and a future version stops throwing said exception it is not co=
nsidered a BC Break. Of course, throwing a <b>different exception</b>=C2=A0=
not part of the hierarchy is a BC break. But when an exception signals &quo=
t;I cannot handle this&quot; and a future version becomes capable of handli=
ng it, that in essence is a feature/enhancement and not treated as a BC bre=
ak. With &quot;Cancellation by Design&quot; we are expected that every coro=
utine be cancellable and that we must write try / catch to design for cance=
llation. This seems to open up a different development flow where catch blo=
cks can be fundamentally part of the BC promise. One possible alternative w=
ould be e.g. await(Awaitable $awaitable, Closure $cancellation) where the c=
ancellation of a coroutine would trigger the specified Closure. Now, I don&=
#39;t want to dive too much into the trade-offs of these options, what I wa=
nt is to spark the idea that there may be multiple ways to design cancellab=
le coroutines. When I consider that, plus the added fact that the RFC is ve=
ry dense, extensive and hard to digest, wouldn&#39;t it be best to postpone=
 coroutine cancellations altogether? The RFC itself states:<br><br>&gt;=C2=
=A0<span style=3D"color:rgb(51,51,51);font-family:&quot;Fira Sans&quot;,&qu=
ot;Source Sans Pro&quot;,Helvetica,Arial,sans-serif;font-size:16px">=C2=A0[=
...]=C2=A0</span>read operations (database queries, API calls, file reads) =
are typically as frequent as=E2=80=94or even more frequent than=E2=80=94wri=
te operations. Since read operations generally don&#39;t modify state, they=
&#39;re inherently safe to cancel without risking data corruption.</div><di=
v><br></div><div>which not only I agree with, but also want us to focus on =
this very fact. What if the first version of Async PHP provides userland wi=
th the ability to trigger coroutines for reading purposes only? We will not=
 forbid/prevent anybody from shooting themselves if they want to, but we ca=
n still clearly state the design principle that Async PHP is meant to spawn=
 coroutines cancellable by design. There will not be any coroutine markers =
in the future nor there will be assumptions that coroutines written for the=
 1st version of Async PHP must not be cancellable. The assumption is that t=
he first version of Async PHP should be treated as a way to perform read op=
erations only and a future RFC / enhancement will bring cancellation capabi=
lities (be it Closure, Try / Catch, what have you). My reasoning is that th=
is would further reduce the scope of the RFC while still introducing real l=
ife useful async components to PHP, even if at a limited capacity. It gives=
 voters less concepts to understand, digest, agree on and approve and it ex=
tends the opportunity to focus on specific deep aspects of Async PHP in chu=
nks and throughout different stages.</div><div><br></div><span class=3D"gma=
il_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signatur=
e"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div=
 dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Marco Deleu</div></div></div=
></div></div></div></div></div></div>

--000000000000cc09d60642604a1e--