Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128897
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 22 Oct 2025 10:53:46 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "Aaron Piotrowski" <aaron@trowski.com>,
 "PHP Internals" <internals@lists.php.net>
Message-ID: <927f1068-ec9f-4548-984f-fceb7b3e682f@app.fastmail.com>
In-Reply-To: <151800a7-1094-49bc-8e43-c593a74741af@app.fastmail.com>
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>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=2d250640a21e46d489389ff6a7b72e91
From: rob@bottled.codes ("Rob Landers")

--2d250640a21e46d489389ff6a7b72e91
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Wed, Oct 22, 2025, at 10:43, Rob Landers wrote:
> On Wed, Oct 22, 2025, at 10:34, Edmond Dantes wrote:
>> > A simpler solution might be to keep things as they are, but have th=
e non-idempotent constructs be generators of Awaitable instead of non-id=
empotent Awaitables
>> So it=E2=80=99s the same as in C#?
>>=20
>> The problem with this situation is that so far I haven=E2=80=99t been=
 able to
>> find any cases proving that a non-Future object could cause serious
>> failures in the code.
>>=20
>> At the same time, if a select case expression is introduced in the
>> future, it would make more sense for select to work with an awaitable
>> object rather than a Future.
>>=20
>> That=E2=80=99s why I=E2=80=99m not yet sure it=E2=80=99s worth abando=
ning the general behavior
>> unless a convincing argument is found showing that it leads to real
>> problems.
>>=20
>> -- Ed
>>=20
>=20
> The example I gave is probably a good one? If I'm writing framework-y =
code, how do I decide to await once, or in a loop? In other words, how d=
o I detect whether an Awaitable is idempotent or will give a different r=
esult every time? If I'm wrong, I could end up in an infinite loop, or m=
issing results. Further, how do I know whether the last value from an Aw=
aitable is the last value? I think if you could illustrate that in the R=
FC or change the semantics, that'd be fine.
>=20
> =E2=80=94 Rob

Accidentally sent too early: but also, what if there are multiple awaite=
rs for a non-idempotent Awaiter? How do we handle that?

=E2=80=94 Rob
--2d250640a21e46d489389ff6a7b72e91
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Wed, Oct 22, 2025, at 10:43, Rob Landers wrote:</di=
v><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Wed, Oct 22, 20=
25, at 10:34, Edmond Dantes wrote:</div><blockquote type=3D"cite" id=3D"=
qt-qt" style=3D""><div>&gt; A simpler solution might be to keep things a=
s they are, but have the non-idempotent constructs be generators of Awai=
table instead of non-idempotent Awaitables</div><div>So it=E2=80=99s the=
 same as in C#?</div><div><br></div><div>The problem with this situation=
 is that so far I haven=E2=80=99t been able to</div><div>find any cases =
proving that a non-Future object could cause serious</div><div>failures =
in the code.</div><div><br></div><div>At the same time, if a select case=
 expression is introduced in the</div><div>future, it would make more se=
nse for select to work with an awaitable</div><div>object rather than a =
Future.</div><div><br></div><div>That=E2=80=99s why I=E2=80=99m not yet =
sure it=E2=80=99s worth abandoning the general behavior</div><div>unless=
 a convincing argument is found showing that it leads to real</div><div>=
problems.</div><div><br></div><div>-- Ed</div><div><br></div></blockquot=
e><div><br></div><div>The example I gave is probably a good one? If I'm =
writing framework-y code, how do I decide to await once, or in a loop? I=
n other words, how do I detect whether an Awaitable is idempotent or wil=
l give a different result every time? If I'm wrong, I could end up in an=
 infinite loop, or missing results. Further, how do I know whether the l=
ast value from an Awaitable is the last value? I think if you could illu=
strate that in the RFC or change the semantics, that'd be fine.</div><di=
v><br></div><div id=3D"qt-sig121229152">=E2=80=94 Rob</div></blockquote>=
<div><br></div><div>Accidentally sent too early: but also, what if there=
 are multiple awaiters for a non-idempotent Awaiter? How do we handle th=
at?</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></bo=
dy></html>
--2d250640a21e46d489389ff6a7b72e91--