Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128896
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 22 Oct 2025 10:43:08 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "Aaron Piotrowski" <aaron@trowski.com>,
 "PHP Internals" <internals@lists.php.net>
Message-ID: <151800a7-1094-49bc-8e43-c593a74741af@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8DKB+AWp2sWPi_w8ZgLQ_zS2MPNgP6n1G5127Nkk7EgOA@mail.gmail.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>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=386a0fe1174543359252fdd0d705d47c
From: rob@bottled.codes ("Rob Landers")

--386a0fe1174543359252fdd0d705d47c
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 22, 2025, at 10:34, Edmond Dantes wrote:
> > A simpler solution might be to keep things as they are, but have the=
 non-idempotent constructs be generators of Awaitable instead of non-ide=
mpotent 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 abandon=
ing the general behavior
> unless a convincing argument is found showing that it leads to real
> problems.
>=20
> -- Ed
>=20

The example I gave is probably a good one? If I'm writing framework-y co=
de, how do I decide to await once, or in a loop? In other words, how do =
I detect whether an Awaitable is idempotent or will give a different res=
ult every time? If I'm wrong, I could end up in an infinite loop, or mis=
sing results. Further, how do I know whether the last value from an Awai=
table is the last value? I think if you could illustrate that in the RFC=
 or change the semantics, that'd be fine.

=E2=80=94 Rob
--386a0fe1174543359252fdd0d705d47c
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Wed, Oct =
22, 2025, at 10:34, Edmond Dantes wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>&gt; A simpler solution might be to keep thing=
s as they are, but have the non-idempotent constructs be generators of A=
waitable 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 situat=
ion is that so far I haven=E2=80=99t been able to</div><div>find any cas=
es proving that a non-Future object could cause serious</div><div>failur=
es in the code.</div><div><br></div><div>At the same time, if a select c=
ase expression is introduced in the</div><div>future, it would make more=
 sense 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 y=
et sure it=E2=80=99s worth abandoning the general behavior</div><div>unl=
ess a convincing argument is found showing that it leads to real</div><d=
iv>problems.</div><div><br></div><div>-- Ed</div><div><br></div></blockq=
uote><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=
? In other words, how do I detect whether an Awaitable is idempotent or =
will 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 th=
e last value from an Awaitable is the last value? I think if you could i=
llustrate that in the RFC or change the semantics, that'd be fine.<br></=
div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></=
html>
--386a0fe1174543359252fdd0d705d47c--