Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128851
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <bcd8253c-04f3-4046-b51f-2e387e215f6d@app.fastmail.com> <CAMW7n8BfP7h5rpDrjigu0oWK4Z+aRaqGjgzEFS_mDXRhq19vQQ@mail.gmail.com>
 <2b9fd3ec-50ca-41e4-985a-274f886df8b3@app.fastmail.com> <CAMW7n8C5GD+F2KdCZTtZwFbc2rk_4yGgdiak8fs9y5Z3UU_zxg@mail.gmail.com>
 <2e39e211-c816-41db-a079-f2c6b3934e0a@app.fastmail.com>
In-Reply-To: <2e39e211-c816-41db-a079-f2c6b3934e0a@app.fastmail.com>
Date: Thu, 16 Oct 2025 09:38:01 +0200
Message-ID: <CAKXKfQtO+yoFB1=6zonwgGRpx1YExBNSkcjpso51aJ59YzaDLQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002a78f7064141b38e"
From: daniil.gentili@gmail.com (Daniil Gentili)

--0000000000002a78f7064141b38e
Content-Type: text/plain; charset="UTF-8"

> You've provided examples and said that it violates design and fundamental
elements, but not which design and fundamentals, ie, the evidence for the
decision. I would expect more than "because I said so" for such a huge
language feature, but rather arguments grounded in computer science.


He very explicitly described the issue, in objective terms: a breach of
agreement in the context of the invocation of a foreign interface.

In simpler terms, you can't and should not be able to mess with the
internals of code you didn't write: this is similar to the principle of
encapsulation in OOP, where you cannot modify private properties of an
object.

Cancellation should be part of the contract of an async function: it is
safe, and most async languages already implement it explicitly by passing a
context or a cancellation token, the current approach of the RFC does it
implicitly, which is also fine.

Awaiting for the completion of spawned coroutines should *not* be part of
the contract of an async function: it is an incredibly easy footgun, as
it's incredibly easy to spawn a coroutine meant to i.e. run until the
object is destroyed, and then encounter a deadlock when the linked scope is
awaited for before the object is destroyed (even messier if cycles and thus
the GC are involved).

Languages like Kotlin that do implement await on scopes have already
realized that it is a mistake, as can be seen by the many warnings against
using await on a scope, as I already linked in previous emails.

On the other hand, making the same mistake described above, by cancelling a
scope, will produce a very easy to debug exception instead of a deadlock,
easily fixable by (warning the author of the library class) to use a new
scope to spawn coroutines within the object.

Awaiting a scope leads to deadlocks in case where a separate scope is
needed but not used, cancelling them leads to a simple exception.
Awaiting on multiple tasks can already be done, explicitly, with TaskGroup.


Regards,
Daniil Gentili.

--0000000000002a78f7064141b38e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; You=
9;ve provided examples and said that it violates design and fundamental ele=
ments, but not which design and fundamentals, ie, the evidence for the deci=
sion. I would expect more than &quot;because I said so&quot; for such a hug=
e language feature, but rather arguments grounded in computer science.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">He very explicitly described the issue, in objective terms: a bre=
ach of agreement in the context of the invocation of a foreign interface.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">In simpler terms, you can=
&#39;t and should not be able to mess with the internals of code you didn&#=
39;t write: this is similar to the principle of encapsulation in OOP, where=
 you cannot modify private properties of an object.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto"></div><div dir=3D"auto">Cancellation should be =
part of the contract of an async function: it is safe, and most async langu=
ages already implement it explicitly by passing a context or a cancellation=
 token, the current approach of the RFC does it implicitly, which is also f=
ine.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Awaiting for the co=
mpletion of spawned coroutines should *not* be part of the contract of an a=
sync function: it is an incredibly easy footgun, as it&#39;s incredibly eas=
y to spawn a coroutine meant to i.e. run until the object is destroyed, and=
 then encounter a deadlock when the linked scope is awaited for before the =
object is destroyed (even messier if cycles and thus the GC are involved).<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto"><span style=3D"font-size=
:10pt">Languages like Kotlin that do implement await on scopes have already=
 realized that it is a mistake, as can be seen by the many warnings against=
 using await on a scope, as I already linked in previous emails.</span></di=
v><div dir=3D"auto"><span style=3D"font-size:10pt"><br></span></div><div di=
r=3D"auto"><span style=3D"font-size:10pt">On the other hand, making the sam=
e mistake described above, by cancelling a scope, will produce a very easy =
to debug exception instead of a deadlock, easily fixable by (warning the au=
thor of the library class) to use a new scope to spawn=C2=A0</span><span st=
yle=3D"font-size:10pt">coroutines within the object.</span></div><div dir=
=3D"auto"><span style=3D"font-size:10pt"><br></span></div><div dir=3D"auto"=
><span style=3D"font-size:10pt">Awaiting a scope leads to deadlocks in case=
 where a separate scope is needed but not used, cancelling them leads to a =
simple exception.</span></div><div dir=3D"auto"><span style=3D"font-size:10=
pt">Awaiting on multiple tasks can already be done, explicitly, with TaskGr=
oup.</span></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Regards,</div><div dir=3D"auto">Daniil Gentili.</div></div>

--0000000000002a78f7064141b38e--