Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128838
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <CADuktwNP+t-DJbLCsnHHhztZYmOMGYde9rzNm+9B0SUsrNvV-g@mail.gmail.com>
 <CAMW7n8BTb1OHdLsjD+fPyeGOkYSQx-KXMrLnG-4rVUSq2646+Q@mail.gmail.com>
 <14f591d4-aa1e-49dc-bc20-03cb493dc20c@app.fastmail.com> <CAMW7n8C6vSxSEiA=5zntf4Yu9H1yPE+LrG_SZns7YA1Lxim1oA@mail.gmail.com>
 <CADK1yX+0+Nu9Srqe0CYmDmFWfxRoVrDy=bDnHg6YTmNTwKKtnA@mail.gmail.com>
 <CAMW7n8BWvf-bE6g7A_0vDW1Lf8hhTm-zuyNEY23DA0biNS-YSA@mail.gmail.com>
 <c2aa62a2-da4b-4caa-99b3-e286ca5ced76@app.fastmail.com> <4f9b8dfd-5415-3df3-fda9-33a8716c57c1@php.net>
 <CAMW7n8BG=GsqrQ-D6rekRgYOg0y_SUJksio7Y-uQKSs97zixEg@mail.gmail.com> <d4c99ddc-d62f-4574-a798-80fa7b1d3e1c@app.fastmail.com>
In-Reply-To: <d4c99ddc-d62f-4574-a798-80fa7b1d3e1c@app.fastmail.com>
Date: Tue, 14 Oct 2025 19:19:32 +0300
Message-ID: <CAMW7n8CAd3P1egRkeHBsrMk7YOEdiSvVgm5teyCZ7EOysC7q1g@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

> It's vastly improved from the first version back in the spring, but there=
 are still numerous footguns

Which specific footguns? $scope var?

> Mainly, we should not be allowing anything but structured
If you always follow the =E2=80=9Cnursery=E2=80=9D rules, you always have t=
o define a
coroutine just to create a nursery, even when the coroutine itself
isn=E2=80=99t actually needed.
That=E2=80=99s why we end up with hacks like =E2=80=9CTask.detached.=E2=80=
=9D (*Swift*). And
*Kotlin* keeps trying to invent workarounds.

**TrueAsync RFC** takes a different approach and gives the programmer
maximum flexibility while still complying with every principle of
structured concurrency.
At the same time, the programmer gains two styles of structured
concurrency organization, one of which fully matches Trio.

> I very much want to see it evolve further in that direction before a vote=
 is called and we're locked into a system with so many foot guns built in.

Such an approach would require more changes to the code, and I don=E2=80=99=
t
see how it would protect the programmer from mistakes any better than
this RFC does.
Of course, the with-style syntax would allow for maximum safety when
working with tasks, but that=E2=80=99s not an issue with this RFC.

The **Trio** model is not perfect; Kotlin and other languages do not
adopt it (maybe by accident =E2=80=94 or maybe not).
It=E2=80=99s not suitable for all types of tasks, which is why the criticis=
m is valid.

Although Kotlin is criticized for storing Scope inside objects like:
=E2=80=9CLong-living CoroutineScope stored in objects almost always lead to
resource leaks or forgotten jobs.=E2=80=9D
However, there is no other way to solve the problem when coroutines
need to be launched within a Scope gradually rather than all at once.

But... Ok...
```python
async def background_manager():
    async with trio.open_nursery() as nursery:
        while True:
            event =3D await get_next_event()
            nursery.start_soon(handle_event, event)
```
^^^
The example of how the pursuit of an =E2=80=9Cideal=E2=80=9D ends up produc=
ing ugly code.

My position is this: **TrueAsync** should support the best patterns
for specific use cases while still remaining convenient for the
majority of tasks.
The fact that certain tools require careful handling applies to all
programming languages. That doesn=E2=80=99t mean those tools shouldn=E2=80=
=99t exist.