Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128933
Content-Type: text/plain;
	charset=utf-8
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
In-Reply-To: <CAMW7n8AZxiHRMbVbUFZfj=O4X68HkfoTzA8tLO407zHGiWXLTQ@mail.gmail.com>
Date: Thu, 23 Oct 2025 12:01:35 -0400
Cc: Rob Landers <rob@bottled.codes>,
 Aleksander Machniak <alec@alec.pl>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F871B5D0-AC67-4697-B6A2-0462CF335B7E@zort.net>
References: <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <0e4e39d6-9cc9-4970-92e0-2463143b4011@app.fastmail.com>
 <CAMW7n8AgHnO0rBjqBkHNhfvV5PBNxwgHBJ762N3FtVxoh5WnOQ@mail.gmail.com>
 <E8D4A549-79EA-48E9-9D20-3608F357F227@trowski.com>
 <CAMW7n8D0wMNQE0zuMhbHstyZsDw=e7ryPPZERn11UFV7knmR-g@mail.gmail.com>
 <37180d8d-85b4-49a3-a672-334bf4329470@app.fastmail.com>
 <CAMW7n8AFaUByiJ=2frgkAFWNPWHS2wYyHiKfwf8dzT7AYnLjWg@mail.gmail.com>
 <2f8524a7-dea2-4fbf-933a-c538d3706253@app.fastmail.com>
 <CAMW7n8DKB+AWp2sWPi_w8ZgLQ_zS2MPNgP6n1G5127Nkk7EgOA@mail.gmail.com>
 <151800a7-1094-49bc-8e43-c593a74741af@app.fastmail.com>
 <CAMW7n8CWMpUmVB+FHjuYNFMzswbW5Lo19C1D6CTri6HVsddwkQ@mail.gmail.com>
 <c1f712d7-4922-4620-a1c6-e8fca72c9a55@app.fastmail.com>
 <CAMW7n8B_+fBQEWoB6f2nNM7CPH5MfAHQ154dbyMLmDCS6-4Mhw@mail.gmail.com>
 <C3EEAC36-A8ED-4B82-BDFC-879EF923E079@zort.net>
 <CAMW7n8D3m-dsBJyq-vk09ft5Vx+6yHc8wrv2sbJ3EMVp+i4m=A@mail.gmail.com>
 <C92EA4F8-F76F-4B84-B573-5154D4A1C86E@zort.net>
 <CAMW7n8AZxiHRMbVbUFZfj=O4X68HkfoTzA8tLO407zHGiWXLTQ@mail.gmail.com>
To: Edmond Dantes <edmond.ht@gmail.com>
From: jbafford@zort.net (John Bafford)

Hi,

> On Oct 23, 2025, at 01:56, Edmond Dantes <edmond.ht@gmail.com> wrote:
>=20
> Hi,
>=20
>> it makes that future RFC's job unnecessary harder
>=20
> If you want to make PHP multithreaded and plan to change the language
> syntax while avoiding future issues, it would be reasonable to discuss
> the changes using specific syntax examples.
> Can you show me the cases you want to implement?

I don't have any specific use-cases in mind. I'm just trying to be =
forward-looking here. But what is clear is that some people would like =
to see async/await in PHP. This RFC would ostensibly be a step towards =
that. All I'm trying to do is make sure that it doesn't put up =
roadblocks for future enhancements.


>> I can't find where this `awaitXX` function is defined
> It was in the third version of the RFC.
>=20
>> So you say "Awaitable objects do not return multiple values.
>=20
> 1. multiple values:
>=20
> ```php
> $fs =3D new FileSystemEvents();
>=20
> // At that moment, the user created file1 and then file2.
> $event =3D await($fs);
>=20
> // Now: $event contains [file1, file2] -- The coroutine captured two
> events at once.
> ```
>=20
> 2. signe value:
>=20
> ```php
> $fs =3D new FileSystemEvents();
>=20
> // At that moment, the user created file1 and then file2.
> $event =3D await($fs);
>=20
> // Now: $event contains file1 -- ONLY ONE VALUE!
> ```
>=20
>> but to me it feels like you're just dismissing Rob and my concern
> It=E2=80=99s hard three times over, because the expression =
foreach(await() as
> ) is considered valid only if await returns a value once.

I think there are two bad designs here.

First: If you have something that streams results, then the interface to =
access should reflect streaming. And it should be an error (preferably =
thrown at compile time) if you try and treat a stream as a single value, =
or a single value as a stream. This is whether it's async or not. And we =
already have an interface one can implement if one has an iterable =
sequence of events, so that you can either call the iteration functions =
directly, or use foreach() which provides syntactic sugar over that.

Second: it should be emitting either a stream of files, or a stream of =
arrays of files. Returning list<File>|File is not a great pattern.


>> btw, if you haven't read through the Swift Evolution proposals for =
structured concurrency,
> Thanks for the idea. I haven=E2=80=99t read that discussion.
> Is it https://forums.swift.org/t/se-0304-structured-concurrency/45314 =
?

That's the first review thread for Swift's Structured Concurrency =
proposal. The proposal itself is here, along with links to the three =
pitch and three review threads, and the async/await and actor proposals:
	=
https://github.com/swiftlang/swift-evolution/blob/main/proposals/0304-stru=
ctured-concurrency.md

(see also the async/await and actors proposals, linked from that =
proposal. Note that a nontrivial portion of the proposal covers actor =
isolation, which is obviously beyond the scope of this RFC, but whether =
or not a future multithreading async extension uses actor isolation as =
its safety concept, those concepts are still generally relevant.)



>> What I'm proposing that specifically Async\protect() and *forcibly* =
cancelling coroutines should be removed.
> This RFC does not include forced coroutine termination, only
> cooperative cancellation using exceptions.
> If we remove the protect function, we=E2=80=99ll also have to remove
> cooperative cancellation.

Why is the protect function needed, then? If you request cancellation, =
the coroutine is free to ignore the cancellation and run to completion. =
That's what makes it cooperative.


>> The RFC should include a description of _why_ cooperative =
cancellation has been chosen.
> If I add detailed explanations for every _why_ in the RFC, it might
> never get read :)

In addition to Rob's comments on expressing intent and a source for =
documentation: concurrency is a large, confusing, and _hard_ topic. =
Anything that's unclear or underspecified is only going to cause =
problems in the long run. It's better to be as clear as possible so that =
when it eventually comes to voting, you have less chance of people =
voting No because of that reason.


> Thanks, Ed

-John=