Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128915
Precedence: list
MIME-Version: 1.0
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>
In-Reply-To: <C92EA4F8-F76F-4B84-B573-5154D4A1C86E@zort.net>
Date: Thu, 23 Oct 2025 08:56:48 +0300
Message-ID: <CAMW7n8AZxiHRMbVbUFZfj=O4X68HkfoTzA8tLO407zHGiWXLTQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
To: John Bafford <jbafford@zort.net>
Cc: Rob Landers <rob@bottled.codes>, Aleksander Machniak <alec@alec.pl>, 
	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)

Hi,

> it makes that future RFC's job unnecessary harder

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 can't find where this `awaitXX` function is defined
It was in the third version of the RFC.

> So you say "Awaitable objects do not return multiple values.

1. multiple values:

```php
$fs =3D new FileSystemEvents();

// At that moment, the user created file1 and then file2.
$event =3D await($fs);

// Now: $event contains [file1, file2] -- The coroutine captured two
events at once.
```

2. signe value:

```php
$fs =3D new FileSystemEvents();

// At that moment, the user created file1 and then file2.
$event =3D await($fs);

// Now: $event contains file1 -- ONLY ONE VALUE!
```

> 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.

> And Swift does recognize this as a problem
I don=E2=80=99t know whether Swift actually recognizes it as a problem or n=
ot,
but it actively uses syntax to describe contracts.
And that=E2=80=99s a slightly different level of control compared to just
functions and interfaces.

Let me repeat the main conclusions:

1. There=E2=80=99s no problem making `FutureLike` the base interface, which
would guarantee the idempotence of the data source.
2. The benefit is that calling `await` twice would become more
predictable (although the data type would still be unknown).
3. However, we would lose an interface that describes the real world
as it is, and the programmer would lose some flexibility.
4. Yet, considering that non-idempotent `Awaitable` objects, while
allowed, are rarely used in high-level languages, this may not
actually be a problem.

> Then, just saying, this is a place where people are going to be confused,=
 and it needs to be stated clearly.
I don=E2=80=99t mind; I should take a look at this point.

> btw, if you haven't read through the Swift Evolution proposals for struct=
ured 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 ?

> What I'm proposing that specifically Async\protect() and *forcibly* cance=
lling 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.

> You'll note that in some multithreading APIs, forcibly terminating thread=
s, while allowed
This feature was implemented in Swow using the VM interruption mechanism.
That=E2=80=99s why I wrote that such a solution is possible if someone need=
s
it, but it has nothing to do with either protect or cooperative
cancellation.

> The RFC should include a description of _why_ cooperative cancellation ha=
s been chosen.
If I add detailed explanations for every _why_ in the RFC, it might
never get read :)

Thanks, Ed