Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129256
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
 <CAMW7n8Dp3siTp0NKGc=-8aNg=Mqoxug9Osgn2399P1v4wi3n5Q@mail.gmail.com>
 <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com> <CAMW7n8CeDFSaN0e4Kr=1jrJyHEonHokfxcY4gdf6L3FqdH1FZQ@mail.gmail.com>
 <3e0cf0a1-c1a3-4e05-97ba-0eeb7f559a53@app.fastmail.com> <CAMW7n8AX7O7x99KGdPSai6sPP1Xd6V4ojQ7CEWmxthNLPM2hyQ@mail.gmail.com>
 <d17e07bf-9664-48e8-b7c4-39142f3cfbf2@app.fastmail.com> <CAMW7n8D3Mq6PveYxvfx=Djx6GnpkECOsEsEc2yKtJACAkAoLpQ@mail.gmail.com>
 <D0376B5C-7054-4948-BC48-5257F57B6129@zort.net>
In-Reply-To: <D0376B5C-7054-4948-BC48-5257F57B6129@zort.net>
Date: Sun, 16 Nov 2025 06:56:13 +0200
Message-ID: <CAMW7n8Da3MUxSoxMTrWeQxmO1vmB5GH1dezVw+2=0fhDvkU24w@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 5
To: John Bafford <jbafford@zort.net>
Cc: Rob Landers <rob@bottled.codes>, php internals <internals@lists.php.net>, 
	Jakub Zelenka <bukka@php.net>, Larry Garfield <larry@garfieldtech.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

> Now this array_map function potentially suspends. As of course does this =
writeData(). And whatever calls this writeData(). And so on up the stack.

And the most important thing is that the __execution flow__ for this
function will __not change__.
Do you understand this?
This is described very clearly in the RFC.

> Because this RFC *changes the contract* out from every line of php code e=
ver written. Code that used to be strictly synchronous now has async suspen=
sion points it didn't ask for.

It=E2=80=99s not the RFC that changes the contract. It=E2=80=99s asynchrono=
us
programming that changes the contract. And that lies outside the scope
of this RFC, because once a developer starts using asynchronous
programming, they must accept the global contracts of asynchronous
execution.
And this RFC does not deny that.

> To repeat, a core premise of this RFC is:
Sorry, but I=E2=80=99m not going to repeat points that were ignored. My goa=
l
is to help you understand the text of this RFC. I have no intention of
banging my head against a wall.

> With this, the RFC implies that I should be able to take my synchronous P=
HP code and run it in a coroutine with other synchronous PHP code, and it w=
ill all just work. But obviously that won't work.
For most cases that=E2=80=99s exactly how it works.
In human language, there is no definition that cannot be twisted and
misinterpreted. Why elevate this idea to an absolute while ignoring
common sense? I have no idea. What=E2=80=99s the purpose of this discussion=
?
It seemed to me that the purpose of the discussion was a professional
conversation, not playing with meanings.

> I understand that a different interpretation of this wording is, "well, t=
hat code does exactly what it did before, just that with coroutines, that h=
appens to be broken".
I have no idea what you=E2=80=99re talking about.

> Of course colored functions are inconvenient. But it's necessary or else =
you open to a whole class of easily avoidable problems. _Those_ problems ar=
e _much_ more inconvenient than colored functions.
I already discussed this topic back in March, and I can briefly
summarize: the absence of colored functions in PHP is the only viable
way to implement async.

> Code that was written to be synchronous should remain synchronous unless =
it is explicitly modified to be asynchronous.
Practice has proven the opposite.

> What this says to me is, "Here's a foot-gun. Please use it responsibly."
A footgun implies something hidden or implicit.
Asynchronous programming requires the developer to handle memory
correctly explicitly. This is equally true for all programming
languages.
It does not relate specifically to this RFC.

>  especially when we have the knowledge and experience from other language=
s to draw on and do better

How do you plan to draw on the experience of other languages if you=E2=80=
=99re
ignoring the experience of asynchronous PHP that has existed for many
years? If you truly wanted to rely on such experience, there wouldn=E2=80=
=99t
be this discussion.