Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128901
Precedence: list
MIME-Version: 1.0
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>
In-Reply-To: <c1f712d7-4922-4620-a1c6-e8fca72c9a55@app.fastmail.com>
Date: Wed, 22 Oct 2025 15:57:35 +0300
Message-ID: <CAMW7n8Ah3LZDqV1eNoM45GWR2yOVLZxR58YuszbSNi34PMA4gw@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
To: Rob Landers <rob@bottled.codes>
Cc: Aaron Piotrowski <aaron@trowski.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

>
> If you await a value, everything works, but then someone somewhere else a=
waits the same Awaitable that wasn't actually a "one-shot" Awaitable,
> so now everything breaks sometimes, and other times not -- depending on w=
hich one awaits first.
>

There is a function:

```php
function my(mixed $i)
{
    return $x + 5;
}
```

Someone called it like this somewhere: my("string"), and the code broke.
The question is: what should be done?

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.

> 2. memoization becomes an issue

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.

So what exactly is the problem with the interface itself?

> 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?

```php
function getOnce(Awaitable $some) {

  if($some instanceof FutureLike =3D=3D=3D false) {
     return await($some);
  }

  static $cache =3D [];
  $id =3D spl_object_id($some);
  return $cache[$id] ??=3D await($some);
}
```

> 3. static analysis
I really don=E2=80=99t see how static analysis could help here. What exactl=
y
would it be checking?

> 4. violation of algebraic laws with awaitAll/awaitAny

And the fact that awaitAll/awaitAny are designed to correctly handle
Awaitable objects?
I=E2=80=99m not aware of any such violations.

> 5. violation of own invariants in the RFC
Can you show which statement of the RFC is being violated here?
What invariants?

> 6. common patterns aren't guaranteed anymore

So JavaScript yes?

```js
class NonIdempotentThenable {
  constructor() {
    this.count =3D 0;
  }
  then(resolve, reject) {
    this.count++;
    resolve(this.count);
  }
}

async function demo() {
  const obj =3D new NonIdempotentThenable();
  console.log(await obj); // 1
  console.log(await obj); // 2
  console.log(await obj); // 3

  if (await obj) {
    console.log(await obj); // 5
  }
}

demo();
````

Other cases generally have the same problem =E2=80=94 a violation of the ag=
reement.