Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128903
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 22 Oct 2025 16:03:38 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "Aaron Piotrowski" <aaron@trowski.com>,
 "PHP Internals" <internals@lists.php.net>
Message-ID: <772a457f-69b6-4a76-8224-081917d719f6@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8Ah3LZDqV1eNoM45GWR2yOVLZxR58YuszbSNi34PMA4gw@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>
 <151800a7-1094-49bc-8e43-c593a74741af@app.fastmail.com>
 <CAMW7n8CWMpUmVB+FHjuYNFMzswbW5Lo19C1D6CTri6HVsddwkQ@mail.gmail.com>
 <c1f712d7-4922-4620-a1c6-e8fca72c9a55@app.fastmail.com>
 <CAMW7n8Ah3LZDqV1eNoM45GWR2yOVLZxR58YuszbSNi34PMA4gw@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=16b1a45c7e3c425baf6bb3f36341034a
From: rob@bottled.codes ("Rob Landers")

--16b1a45c7e3c425baf6bb3f36341034a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 22, 2025, at 14:57, Edmond Dantes wrote:
> >
> > If you await a value, everything works, but then someone somewhere e=
lse awaits the same Awaitable that wasn't actually a "one-shot" Awaitabl=
e,
> > so now everything breaks sometimes, and other times not -- depending=
 on which one awaits first.
> >
>=20
> There is a function:
>=20
> ```php
> function my(mixed $i)
> {
>     return $x + 5;
> }
> ```
>=20
> Someone called it like this somewhere: my("string"), and the code brok=
e.
> The question is: what should be done?
>=20
> Do we really have to get rid of the mixed type just to prevent someone
> from breaking something?
> If a programmer explicitly violates the contracts in the code and then
> blames the programming language for it. So the programmer is the one
> at fault.
> If someone uses a contract that promises non-idempotent behavior, it=E2=
=80=99s
> logical to rely on that.

This isn't even the same example. We're not talking about type juggling,=
 but an interface. Mixed is not an object nor an interface.

> > 2. memoization becomes an issue
>=20
> The same question: why should the code work correctly if the
> agreements are violated at the contract level?
> There=E2=80=99s no element of randomness here.
> 1. A person deliberately found the Awaitable interface and inserted it
> into the code.
> 2. They deliberately wrote that function.
>=20
> So what exactly is the problem with the interface itself?
>=20
> > With a "multi-shot" Awaitable, this is not practical or even a good =
idea. You can't write general-purpose helpers, at all.
> In what way are generalized types a problem?
> Why not just use the contracts correctly?
>=20
> ```php
> function getOnce(Awaitable $some) {
>=20
>   if($some instanceof FutureLike =3D=3D=3D false) {
>      return await($some);
>   }
>=20
>   static $cache =3D [];
>   $id =3D spl_object_id($some);
>   return $cache[$id] ??=3D await($some);
> }
> ```

The "FutureLike" type is exactly what I'm arguing for!

> > 3. static analysis
> I really don=E2=80=99t see how static analysis could help here. What e=
xactly
> would it be checking?

I can imagine getting something like the following

foreach($next =3D await($awaitable)) { }
*error*: usage of single-shot Awaitable in loop, this is an infinite loop

or:

$val =3D await($awaitable);
//in another file/function/5 lines later/etc
$val =3D await($awaitable);
*error*: multiple usages of multi-shot Awaitable; you may get a differen=
t result on each invocation of await()

or something like that.

>=20
> > 4. violation of algebraic laws with awaitAll/awaitAny
>=20
> And the fact that awaitAll/awaitAny are designed to correctly handle
> Awaitable objects?
> I=E2=80=99m not aware of any such violations.

I had to go take a look at the implementation. It appears NOT to handle =
this case, at all. Meaning it treats all Awaitables passed to it as a si=
ngle-shot Awaitable. (the code was easy to follow, but maybe I missed so=
mething). The RFC doesn't spell this out and needs some work here.

When I say "violations" I mean that, assuming $a and $b resolve instantl=
y:

awaitAll([$a, $b]) !=3D=3D [await($a), await($b)]
awaitAny([delay(10, fn() =3D> await($a), await($b)]) !=3D=3D await($b)

>=20
> > 5. violation of own invariants in the RFC
> Can you show which statement of the RFC is being violated here?
> What invariants?

sidenote: It would really help to include the full context of the emails=
 you're replying to so I don't have to open our email conversation in an=
other window to see exactly what I wrote.

This is my mistake though. The discussion about await() is all mixed up =
with coroutines so its hard to tell what the actual behaviour for await(=
) is outside of the context of coroutines. The violation I thought of on=
ly applies to coroutines, the actual behaviour is "undefined" in the RFC.

>=20
> > 6. common patterns aren't guaranteed anymore
>=20
> So JavaScript yes?
>=20
> ```js
> class NonIdempotentThenable {
>   constructor() {
>     this.count =3D 0;
>   }
>   then(resolve, reject) {
>     this.count++;
>     resolve(this.count);
>   }
> }
>=20
> async function demo() {
>   const obj =3D new NonIdempotentThenable();
>   console.log(await obj); // 1
>   console.log(await obj); // 2
>   console.log(await obj); // 3
>=20
>   if (await obj) {
>     console.log(await obj); // 5
>   }
> }
>=20
> demo();
> ````
>=20
> Other cases generally have the same problem =E2=80=94 a violation of t=
he agreement.

But you're talking about this being *the default*. There's a reason this=
 is an anti-pattern in Javascript and violation of the 'agreement' there.

>> how will the scheduler handle backpressure?
>=20
> I don=E2=80=99t really understand the problem with the Scheduler, and =
even
> less its relation to backpressure.
> Dealing with backpressure is a matter of queue implementation.
> The Awaitable contract has nothing to do with this situation.

It has everything to do with it! If a multi-shot Awaitable keeps emittin=
g, this causes repeated wakeups to the same continuation. It has to sche=
dule this *every time* and there isn't a way to say "don't produce until=
 consumed". You can basically starve other tasks from executing. However=
, if you use iterables of single-shot Awaitables, you get backpressure "=
for free" and don't request the next future until the previous one is co=
mplete, otherwise, the buffering pressure lands in the awaitable (unboun=
ded memory) or in the schedulers ready queue (which affects fairness). F=
urther, when cancelling a multi-shot awaitable, should the scheduler dro=
p pending emissions and what happens if it keeps re-enqueing it anyway? =
It makes the scheduler far more complicated than it needs to be!

>> I'm not sure what your thought process is here, because in the last f=
ew emails you've gone from "maybe"
>> to doubling-down on this (from my perspective), but I feel like this =
will be a footgun to both developers and the future of the language.
>=20
> Confident about what exactly?
> And what exactly would be the footgun?
> These are very general statements.
>=20
> It seems to me that people in this conference use the word =E2=80=9Cfo=
otgun=E2=80=9D
> far too often =E2=80=94 and not always in the right context.
> There=E2=80=99s a lack of rational boundaries here.
> Not every programmer=E2=80=99s mistake is a footgun.
> Especially that:
>=20
> ```php
> if (await($response)) {
>   return await($response);
> }
> ```

A footgun is any reasonable looking code that subtly breaks because the =
contract is weak, not because the programmer didn't RTFM.

=E2=80=94 Rob
--16b1a45c7e3c425baf6bb3f36341034a
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 14:57, Edmond Dantes wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>&gt;</div><div>&gt; If you await a value, ever=
ything works, but then someone somewhere else awaits the same Awaitable =
that wasn't actually a "one-shot" Awaitable,</div><div>&gt; so now every=
thing breaks sometimes, and other times not -- depending on which one aw=
aits first.</div><div>&gt;</div><div><br></div><div>There is a function:=
</div><div><br></div><div>```php</div><div>function my(mixed $i)</div><d=
iv>{</div><div>&nbsp;&nbsp;&nbsp; return $x + 5;</div><div>}</div><div>`=
``</div><div><br></div><div>Someone called it like this somewhere: my("s=
tring"), and the code broke.</div><div>The question is: what should be d=
one?</div><div><br></div><div>Do we really have to get rid of the mixed =
type just to prevent someone</div><div>from breaking something?</div><di=
v>If a programmer explicitly violates the contracts in the code and then=
</div><div>blames the programming language for it. So the programmer is =
the one</div><div>at fault.</div><div>If someone uses a contract that pr=
omises non-idempotent behavior, it=E2=80=99s</div><div>logical to rely o=
n that.</div></blockquote><div><br></div><div>This isn't even the same e=
xample. We're not talking about type juggling, but an interface. Mixed i=
s not an object nor an interface.</div><div><br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>&gt; 2. memoization becomes an issue</d=
iv><div><br></div><div>The same question: why should the code work corre=
ctly if the</div><div>agreements are violated at the contract level?</di=
v><div>There=E2=80=99s no element of randomness here.</div><div>1. A per=
son deliberately found the Awaitable interface and inserted it</div><div=
>into the code.</div><div>2. They deliberately wrote that function.</div=
><div><br></div><div>So what exactly is the problem with the interface i=
tself?</div><div><br></div><div>&gt; With a "multi-shot" Awaitable, this=
 is not practical or even a good idea. You can't write general-purpose h=
elpers, at all.</div><div>In what way are generalized types a problem?</=
div><div>Why not just use the contracts correctly?</div><div><br></div><=
div>```php</div><div>function getOnce(Awaitable $some) {</div><div><br><=
/div><div>&nbsp; if($some instanceof FutureLike =3D=3D=3D false) {</div>=
<div>&nbsp;&nbsp;&nbsp;&nbsp; return await($some);</div><div>&nbsp; }</d=
iv><div><br></div><div>&nbsp; static $cache =3D [];</div><div>&nbsp; $id=
 =3D spl_object_id($some);</div><div>&nbsp; return $cache[$id] ??=3D awa=
it($some);</div><div>}</div><div>```</div></blockquote><div><br></div><d=
iv>The "FutureLike" type is exactly what I'm arguing for!</div><div><br>=
</div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt; 3. static=
 analysis</div><div>I really don=E2=80=99t see how static analysis could=
 help here. What exactly</div><div>would it be checking?</div></blockquo=
te><div><br></div><div>I can imagine getting something like the followin=
g</div><div><br></div><div>foreach($next =3D await($awaitable)) { }</div=
><div><b>error</b>: usage of single-shot Awaitable in loop, this is an i=
nfinite loop</div><div><br></div><div>or:</div><div><br></div><div>$val =
=3D await($awaitable);</div><div>//in another file/function/5 lines late=
r/etc</div><div>$val =3D await($awaitable);</div><div><b>error</b>: mult=
iple usages of multi-shot Awaitable; you may get a different result on e=
ach invocation of await()</div><div><br></div><div>or something like tha=
t.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><d=
iv><br></div><div>&gt; 4. violation of algebraic laws with awaitAll/awai=
tAny</div><div><br></div><div>And the fact that awaitAll/awaitAny are de=
signed to correctly handle</div><div>Awaitable objects?</div><div>I=E2=80=
=99m not aware of any such violations.</div></blockquote><div><br></div>=
<div>I had to go take a look at the implementation. It appears NOT to ha=
ndle this case, at all. Meaning it treats all Awaitables passed to it as=
 a single-shot Awaitable. (the code was easy to follow, but maybe I miss=
ed something). The RFC doesn't spell this out and needs some work here.<=
/div><div><br></div><div>When I say "violations" I mean that, assuming $=
a and $b resolve instantly:</div><div><br></div><div> awaitAll([$a, $b])=
 !=3D=3D [await($a), await($b)]</div><div>awaitAny([delay(10, fn() =3D&g=
t; await($a), await($b)]) !=3D=3D await($b)<br></div><div><br></div><blo=
ckquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>&gt; 5. v=
iolation of own invariants in the RFC</div><div>Can you show which state=
ment of the RFC is being violated here?</div><div>What invariants?</div>=
</blockquote><div><br></div><div>sidenote: It would really help to inclu=
de the full context of the emails you're replying to so I don't have to =
open our email conversation in another window to see exactly what I wrot=
e.</div><div><br></div><div>This is my mistake though. The discussion ab=
out await() is all mixed up with coroutines so its hard to tell what the=
 actual behaviour for await() is outside of the context of coroutines. T=
he violation I thought of only applies to coroutines, the actual behavio=
ur is "undefined" in the RFC.</div><div><br></div><blockquote type=3D"ci=
te" id=3D"qt" style=3D""><div><br></div><div>&gt; 6. common patterns are=
n't guaranteed anymore</div><div><br></div><div>So JavaScript yes?</div>=
<div><br></div><div>```js</div><div>class NonIdempotentThenable {</div><=
div>&nbsp; constructor() {</div><div>&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"=
http://this.count">this.count</a> =3D 0;</div><div>&nbsp; }</div><div>&n=
bsp; then(resolve, reject) {</div><div>&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D=
"http://this.count">this.count</a>++;</div><div>&nbsp;&nbsp;&nbsp; resol=
ve(<a href=3D"http://this.count">this.count</a>);</div><div>&nbsp; }</di=
v><div>}</div><div><br></div><div>async function demo() {</div><div>&nbs=
p; const obj =3D new NonIdempotentThenable();</div><div>&nbsp;&nbsp;<a h=
ref=3D"http://console.log">console.log</a>(await obj); // 1</div><div>&n=
bsp;&nbsp;<a href=3D"http://console.log">console.log</a>(await obj); // =
2</div><div>&nbsp;&nbsp;<a href=3D"http://console.log">console.log</a>(a=
wait obj); // 3</div><div><br></div><div>&nbsp; if (await obj) {</div><d=
iv>&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"http://console.log">console.log</a=
>(await obj); // 5</div><div>&nbsp; }</div><div>}</div><div><br></div><d=
iv>demo();</div><div>````</div><div><br></div><div>Other cases generally=
 have the same problem =E2=80=94 a violation of the agreement.</div></bl=
ockquote><div><br></div><div>But you're talking about this being&nbsp;<b=
>the default</b>. There's a reason this is an anti-pattern in Javascript=
 and violation of the 'agreement' there.</div><div><br></div><blockquote=
 type=3D"cite"><blockquote>how will the scheduler handle backpressure?</=
blockquote><div><div><br></div><div>I don=E2=80=99t really understand th=
e problem with the Scheduler, and even</div><div>less its relation to ba=
ckpressure.</div><div>Dealing with backpressure is a matter of queue imp=
lementation.</div><div>The Awaitable contract has nothing to do with thi=
s situation.</div></div></blockquote><div><br></div><div>It has everythi=
ng to do with it! If a multi-shot Awaitable keeps emitting, this causes =
repeated wakeups to the same continuation. It has to schedule this&nbsp;=
<b>every time</b> and there isn't a way to say "don't produce until cons=
umed". You can basically starve other tasks from executing. However, if =
you use iterables of single-shot Awaitables, you get backpressure "for f=
ree" and don't request the next future until the previous one is complet=
e, otherwise, the buffering pressure lands in the awaitable (unbounded m=
emory) or in the schedulers ready queue (which affects fairness). Furthe=
r, when cancelling a multi-shot awaitable, should the scheduler drop pen=
ding emissions and what happens if it keeps re-enqueing it anyway? It ma=
kes the scheduler far more complicated than it needs to be!</div><div><b=
r></div><blockquote type=3D"cite"><blockquote><div>I'm not sure what you=
r thought process is here, because in the last few emails you've gone fr=
om "maybe"</div><div>to doubling-down on this (from my perspective), but=
 I feel like this will be a footgun to both developers and the future of=
 the language.</div></blockquote><div><div><br></div><div>Confident abou=
t what exactly?</div><div>And what exactly would be the footgun?</div><d=
iv>These are very general statements.</div><div><br></div><div>It seems =
to me that people in this conference use the word =E2=80=9Cfootgun=E2=80=
=9D</div><div>far too often =E2=80=94 and not always in the right contex=
t.</div><div>There=E2=80=99s a lack of rational boundaries here.</div><d=
iv>Not every programmer=E2=80=99s mistake is a footgun.</div><div>Especi=
ally that:</div><div><br></div><div>```php</div><div>if (await($response=
)) {</div><div>&nbsp; return await($response);</div><div>}</div><div>```=
</div></div></blockquote><div><br></div><div>A footgun is any reasonable=
 looking code that subtly breaks because the contract is weak, not becau=
se the programmer didn't RTFM.</div><div><br></div><div id=3D"sig1212291=
52">=E2=80=94 Rob</div></body></html>
--16b1a45c7e3c425baf6bb3f36341034a--