Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128906
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 22 Oct 2025 19:05:29 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "Aaron Piotrowski" <aaron@trowski.com>,
 "PHP Internals" <internals@lists.php.net>
Message-ID: <8c20e8cc-cec7-4aa5-b6a7-663ef8159e1a@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8C0BALniMyfCHfgC9qwS41jMZoM0a0u-vyBCjJY=fanLA@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>
 <772a457f-69b6-4a76-8224-081917d719f6@app.fastmail.com>
 <CAMW7n8C0BALniMyfCHfgC9qwS41jMZoM0a0u-vyBCjJY=fanLA@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=237b15f60a91441d82a4c309023f4ea3
From: rob@bottled.codes ("Rob Landers")

--237b15f60a91441d82a4c309023f4ea3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 22, 2025, at 17:30, Edmond Dantes wrote:
> > This isn't even the same example. We're not talking about type juggl=
ing, but an interface. Mixed is not an object nor an interface.
> Why?
> Type and Interface are contracts.
>=20
> > The "FutureLike" type is exactly what I'm arguing for!
>=20
> I have nothing against this interface. My point is different:
> 1. Should the await and awaitXX functions accept only Future?
> 2. Should Awaitable be hidden from the PHP userland?
>=20
> > foreach($next =3D await($awaitable)) { }
> What=E2=80=99s the problem here? The object will return a result.
> If the result is iterable, it will go into the foreach loop. An
> absolutely normal situation.

Assuming an awaitable is idempotent (such as the result of a coroutine),=
 this is an infinite loop. There=E2=80=99s a 99.9% chance that=E2=80=99s=
 unintended, which is part of the point of static analysis.

> > error: multiple usages of multi-shot Awaitable; you may get a differ=
ent result on each invocation of await()
> Why can=E2=80=99t you call await twice? What=E2=80=99s illegal about i=
t?
> If it=E2=80=99s a Future, you=E2=80=99ll get the previous result; if i=
t=E2=80=99s an
> Awaitable, you=E2=80=99ll get the second value.
> But the correctness of the code here 100% depends on the programmer=E2=
=80=99s intent.

There=E2=80=99s no world this would be intentional to get two separate v=
alues in two separate places, especially concurrently, except in very ra=
re circumstances. You can=E2=80=99t guarantee ordering, and I can=E2=80=99=
t imagine wanting to interleave results across multiple code paths. Well=
, I can, but that feels like a very brittle system and a pita to maintai=
n/debug.

>=20
> > The RFC doesn't spell this out and needs some work here.
> I don=E2=80=99t understand what exactly isn=E2=80=99t specified in the=
 RFC?
>=20
> > When I say "violations" I mean that, assuming $a and $b resolve inst=
antly:
> > awaitAll([$a, $b]) !=3D=3D [await($a), await($b)]
> > ...
>=20
> This is a logical error. =D0=A1ircular reasoning. The desired behavior=
 is
> being used here as proof of the undesired one. (recursion)
> In the general case, these equations should not work =E2=80=94 and tha=
t=E2=80=99s
> normal if the code expects entities that are not Future, but, for
> example, channels.

Ok. If it=E2=80=99s circular reasoning, then what=E2=80=99s the definiti=
on of awaitAll? How do we explain it to junior devs, what guarantees can=
 we make from it?

> > 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 aw=
ait() is outside of the context of coroutines.
> > The violation I thought of only applies to coroutines, the actual be=
haviour is "undefined" in the RFC.
>=20
> `await()` does two things:
> 1. Puts the coroutine into a waiting state.
> 2. Wakes it up when the `Awaitable` object emits an event.
>=20
> `awaitAny` / `awaitAll` do the same but for a list of objects or an it=
erator.

The RFC says that for *coroutines, *but not *Awaitable.* It is undefined.

>=20
> However, the result of `await()` depends on the object being awaited.
> Thus, there are two separate contracts here:
> 1. **The waiting contract** =E2=80=94 how the waiting occurs.
> 2. **The result contract** =E2=80=94 how the result is obtained.
>=20
> From a language design perspective, there should be an explicit
> representation for these contracts.
> Something similar appeared only in Swift (e.g., `try await`).
>=20
> So, from the standpoint of =E2=80=9Cperfect design,=E2=80=9D this is a=
 simplification,
> which makes it not ideal.
>=20
> I can remove the `Awaitable` interface from the `RFC` and replace it
> with `FutureLike`. It costs nothing to do so.
> But before doing that, I want to be at least 95% sure that in 2=E2=80=933
> years we won=E2=80=99t have to bring it back or add workarounds.

Bringing it back is much much much easier than taking it away.

>=20
> > It has everything to do with it! If a multi-shot Awaitable keeps emi=
tting, this causes repeated wakeups to the same continuation. It has to =
schedule this every time and there isn't a way to say "don't > produce u=
ntil consumed". You can basically starve other tasks from executing. How=
ever, if you use iterables of single-shot Awaitables, you get backpressu=
re "for free" and don't request the next
> > future until the previous one is complete, otherwise, the buffering =
pressure lands in the awaitable (unbounded memory) or in the schedulers =
ready queue (which affects fairness). Further, when
> > cancelling a multi-shot awaitable, should the scheduler drop pending=
 emissions and what happens if it keeps re-enqueing it anyway? It makes =
the scheduler far more complicated than it needs to > be!
>=20
> If an Awaitable object isn=E2=80=99t being awaited, it can=E2=80=99t e=
mit events, nor
> can it interfere with the scheduler.
> Unless the programmer explicitly creates new coroutines for every even=
t by hand.
> If an Awaitable has a lot of data and wakes up 1000 coroutines, then
> the scheduler will ensure that all those coroutines get executed.
> But until these 1000 coroutines finish processing the data, the
> Awaitable cannot wake anyone else.
> So there is a natural limit to the number of subscribers. it can only
> be exceeded through explicitly incorrect handling of coroutines.
>=20
> Because the scheduler=E2=80=99s algorithm is extremely simple, it has =
little
> to no starvation issues.
> Starvation problems usually arise in schedulers that use more
> =E2=80=9Cintelligent=E2=80=9D approaches.

You=E2=80=99re making some assumptions:
 1. That the scheduler will always be cooperative.
 2. That the scheduler you implemented as a proof-of-concept will be the=
 one shipped.
There=E2=80=99ll come a day where someone will want to write a preemptiv=
e coroutine scheduler, or even a multi-threaded scheduler. That might be=
 in 20=E2=80=9330 years, or next year; we don=E2=80=99t know. But if the=
y do, having Awaitables multi-shot *will* prevent that from being a real=
istic PR. The amount of complexity required for such an implementation w=
ould be huge.

>=20
> > A footgun is any reasonable looking code that subtly breaks because =
the contract is weak, not because the programmer didn't RTFM.
> The code cannot be considered =E2=80=9Creasonable,=E2=80=9D because in=
 this case the
> programmer is clearly violating the contract.
> And not because the contract is complex or confusing, but because they
> completely ignored it. This doesn=E2=80=99t look like a footgun.
>=20

At this point, we=E2=80=99re debating philosophy, but according to the R=
FC, coroutines will be entirely safe to handle this way, but not ALL awa=
itables. *That=E2=80=99s what makes it a footgun.* Sometimes, it=E2=80=99=
s reasonable, and it works ... and in certain cases, it doesn=E2=80=99t =
work at all. Nobody can tell by simply reading the code in a code review=
 unless they had been shot in the foot before.

=E2=80=94 Rob
--237b15f60a91441d82a4c309023f4ea3
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 17:30, Edmond Dantes wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>&gt; This isn't even the same example. We're n=
ot talking about type juggling, but an interface. Mixed is not an object=
 nor an interface.</div><div>Why?</div><div>Type and Interface are contr=
acts.</div><div><br></div><div>&gt; The "FutureLike" type is exactly wha=
t I'm arguing for!</div><div><br></div><div>I have nothing against this =
interface. My point is different:</div><div>1. Should the await and awai=
tXX functions accept only Future?</div><div>2. Should Awaitable be hidde=
n from the PHP userland?</div><div><br></div><div>&gt; foreach($next =3D=
 await($awaitable)) { }</div><div>What=E2=80=99s the problem here? The o=
bject will return a result.</div><div>If the result is iterable, it will=
 go into the foreach loop. An</div><div>absolutely normal situation.</di=
v></blockquote><div><br></div><div>Assuming an awaitable is idempotent (=
such as the result of a coroutine), this is an infinite loop. There=E2=80=
=99s a 99.9% chance that=E2=80=99s unintended, which is part of the poin=
t of static analysis.</div><div><br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div>&gt; error: multiple usages of multi-shot Awaitable=
; you may get a different result on each invocation of await()</div><div=
>Why can=E2=80=99t you call await twice? What=E2=80=99s illegal about it=
?</div><div>If it=E2=80=99s a Future, you=E2=80=99ll get the previous re=
sult; if it=E2=80=99s an</div><div>Awaitable, you=E2=80=99ll get the sec=
ond value.</div><div>But the correctness of the code here 100% depends o=
n the programmer=E2=80=99s intent.</div></blockquote><div><br></div><div=
>There=E2=80=99s no world this would be intentional to get two separate =
values in two separate places, especially concurrently, except in very r=
are circumstances. You can=E2=80=99t guarantee ordering, and I can=E2=80=
=99t imagine wanting to interleave results across multiple code paths. W=
ell, I can, but that feels like a very brittle system and a pita to main=
tain/debug.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" styl=
e=3D""><div><br></div><div>&gt; The RFC doesn't spell this out and needs=
 some work here.</div><div>I don=E2=80=99t understand what exactly isn=E2=
=80=99t specified in the RFC?</div><div><br></div><div>&gt; When I say "=
violations" I mean that, assuming $a and $b resolve instantly:</div><div=
>&gt; awaitAll([$a, $b]) !=3D=3D [await($a), await($b)]</div><div>&gt; .=
..</div><div><br></div><div>This is a logical error. =D0=A1ircular reaso=
ning. The desired behavior is</div><div>being used here as proof of the =
undesired one. (recursion)</div><div>In the general case, these equation=
s should not work =E2=80=94 and that=E2=80=99s</div><div>normal if the c=
ode expects entities that are not Future, but, for</div><div>example, ch=
annels.</div></blockquote><div><br></div><div>Ok. If it=E2=80=99s circul=
ar reasoning, then what=E2=80=99s the definition of awaitAll? How do we =
explain it to junior devs, what guarantees can we make from it?</div><di=
v><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt; Thi=
s is my mistake though. The discussion about await() is all mixed up wit=
h coroutines so its hard to tell what the actual behaviour for await() i=
s outside of the context of coroutines.</div><div>&gt; The violation I t=
hought of only applies to coroutines, the actual behaviour is "undefined=
" in the RFC.</div><div><br></div><div>`await()` does two things:</div><=
div>1. Puts the coroutine into a waiting state.</div><div>2. Wakes it up=
 when the `Awaitable` object emits an event.</div><div><br></div><div>`a=
waitAny` / `awaitAll` do the same but for a list of objects or an iterat=
or.</div></blockquote><div><br></div><div>The RFC says that for&nbsp;<b>=
coroutines, </b>but not&nbsp;<b>Awaitable.</b> It is undefined.</div><di=
v><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></di=
v><div>However, the result of `await()` depends on the object being awai=
ted.</div><div>Thus, there are two separate contracts here:</div><div>1.=
 **The waiting contract** =E2=80=94 how the waiting occurs.</div><div>2.=
 **The result contract** =E2=80=94 how the result is obtained.</div><div=
><br></div><div>From a language design perspective, there should be an e=
xplicit</div><div>representation for these contracts.</div><div>Somethin=
g similar appeared only in Swift (e.g., `try await`).</div><div><br></di=
v><div>So, from the standpoint of =E2=80=9Cperfect design,=E2=80=9D this=
 is a simplification,</div><div>which makes it not ideal.</div><div><br>=
</div><div>I can remove the `Awaitable` interface from the `RFC` and rep=
lace it</div><div>with `FutureLike`. It costs nothing to do so.</div><di=
v>But before doing that, I want to be at least 95% sure that in 2=E2=80=93=
3</div><div>years we won=E2=80=99t have to bring it back or add workarou=
nds.</div></blockquote><div><br></div><div>Bringing it back is much much=
 much easier than taking it away.</div><div><br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div><br></div><div>&gt; It has everything t=
o do with it! If a multi-shot Awaitable keeps emitting, this causes repe=
ated wakeups to the same continuation. It has to schedule this every tim=
e and there isn't a way to say "don't &gt; produce until consumed". You =
can basically starve other tasks from executing. However, if you use ite=
rables of single-shot Awaitables, you get backpressure "for free" and do=
n't request the next</div><div>&gt; future until the previous one is com=
plete, otherwise, the buffering pressure lands in the awaitable (unbound=
ed memory) or in the schedulers ready queue (which affects fairness). Fu=
rther, when</div><div>&gt; cancelling a multi-shot awaitable, should the=
 scheduler drop pending emissions and what happens if it keeps re-enquei=
ng it anyway? It makes the scheduler far more complicated than it needs =
to &gt; be!</div><div><br></div><div>If an Awaitable object isn=E2=80=99=
t being awaited, it can=E2=80=99t emit events, nor</div><div>can it inte=
rfere with the scheduler.</div><div>Unless the programmer explicitly cre=
ates new coroutines for every event by hand.</div><div>If an Awaitable h=
as a lot of data and wakes up 1000 coroutines, then</div><div>the schedu=
ler will ensure that all those coroutines get executed.</div><div>But un=
til these 1000 coroutines finish processing the data, the</div><div>Awai=
table cannot wake anyone else.</div><div>So there is a natural limit to =
the number of subscribers. it can only</div><div>be exceeded through exp=
licitly incorrect handling of coroutines.</div><div><br></div><div>Becau=
se the scheduler=E2=80=99s algorithm is extremely simple, it has little<=
/div><div>to no starvation issues.</div><div>Starvation problems usually=
 arise in schedulers that use more</div><div>=E2=80=9Cintelligent=E2=80=9D=
 approaches.</div></blockquote><div><br></div><div>You=E2=80=99re making=
 some assumptions:</div><ol><li>That the scheduler will always be cooper=
ative.</li><li>That the scheduler you implemented as a proof-of-concept =
will be the one shipped.<br></li></ol><div>There=E2=80=99ll come a day w=
here someone will want to write a preemptive coroutine scheduler, or eve=
n a multi-threaded scheduler. That might be in 20=E2=80=9330 years, or n=
ext year; we don=E2=80=99t know. But if they do, having Awaitables multi=
-shot&nbsp;<b>will</b> prevent that from being a realistic PR. The amoun=
t of complexity required for such an implementation would be huge.</div>=
<div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br><=
/div><div>&gt; A footgun is any reasonable looking code that subtly brea=
ks because the contract is weak, not because the programmer didn't RTFM.=
</div><div>The code cannot be considered =E2=80=9Creasonable,=E2=80=9D b=
ecause in this case the</div><div>programmer is clearly violating the co=
ntract.</div><div>And not because the contract is complex or confusing, =
but because they</div><div>completely ignored it. This doesn=E2=80=99t l=
ook like a footgun.</div><div><br></div></blockquote><div><br></div><div=
>At this point, we=E2=80=99re debating philosophy, but according to the =
RFC, coroutines will be entirely safe to handle this way, but not ALL aw=
aitables.&nbsp;<i>That=E2=80=99s what makes it a footgun.</i> Sometimes,=
 it=E2=80=99s reasonable, and it works ... and in certain cases, it does=
n=E2=80=99t work at all. Nobody can tell by simply reading the code in a=
 code review unless they had been shot in the foot before.</div><div><br=
></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--237b15f60a91441d82a4c309023f4ea3--