Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128907
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 22 Oct 2025 12:24:18 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <2e99b70d-1ca3-4570-a3b3-7cae9dfc101b@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: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Oct 22, 2025, at 10:30 AM, Edmond Dantes wrote:
>> This isn't even the same example. We're not talking about type juggli=
ng, but an interface. Mixed is not an object nor an interface.
> Why?
> Type and Interface are contracts.
>
>> The "FutureLike" type is exactly what I'm arguing for!
>
> 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?
>
>> 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.
>
>> error: multiple usages of multi-shot Awaitable; you may get a differe=
nt 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.

And that's exactly the problem.  The correctness cannot be inferred with=
out asking the programmer.

There is, obviously, no such thing as idiot-proof code, as the world wil=
l always create a better idiot.  But we should still strive to be idiot-=
resistant.  There are two general ways of doing that:=20

1. Affordances - Basically, it should be hard to use wrong. =20
2. Construction - It should be impossible to use wrong in the first plac=
e.  (Ie, a compile error.)

The classic example is US electrical plugs vs EU plugs.  They *should* b=
e different shapes, because they're different voltages.  If you plug an =
unsuspecting device into the wrong voltage, it goes boom.  So the differ=
ent plug interfaces make it patently obvious that you're doing something=
 wrong because they don't fit together (construction), and if you use an=
 adapter that is your signal that you need to worry about voltage conver=
sion (affordance).

Using the same type for something that can be read only once vs somethin=
g that should be read multiple times is equivalent to using the same plu=
g for both 120v and 240v current.  (Or USB-C using the same plug for 8 d=
ifferent speeds, 5 different power delivery levels, and sometimes no dat=
a at all.  It sucks.)  The developer needs to "just know" which one is i=
ntended, because the code doesn't tell them.  That's a problem.

Instead, like Rob said, there should be a one-shot object that dies as s=
oon as it is successfully read.  That is guaranteed to be single-use, an=
d reading it multiple times is detectable by a static analysis tool as "=
you clearly are doing this wrong, no question."

Then a multi-read object is... an Iterable that produces those single sh=
ot objects.  I'm not sure if that even needs its own object that impleme=
nts Iterable, or if it's OK to not define it and just say it's any itera=
ble<Awaitable>.  (So, a generator would work just as well.)  I'm leaning=
 toward the latter, but there may be uses for the former, not sure.

But having a "dual voltage" awaitable object is exactly the sort of foot=
gun many of us are talking about.  The contract is under-specified, so i=
t's too easy for the developer to be "holding it wrong" and plug it into=
 the wrong wall socket.  Boom.

--Larry Garfield