Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129265
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> <CAEUnE0fcNP+R+r6rrMtUXcOYeCkutQzo-fTbkFpdL3VyLVXvQw@mail.gmail.com>
 <CADK1yXKS84aP9m=oExvL=rz2quGvXWKcPkV1h6gQj8vQUJjX3w@mail.gmail.com>
 <CAMW7n8ARHDQUeVKzsd44a11WGSuRm9CpvVK_D9YnBtMp9VxBSw@mail.gmail.com> <bc6b6fe4-0ede-4e34-b7b7-c14c32c3963b@app.fastmail.com>
In-Reply-To: <bc6b6fe4-0ede-4e34-b7b7-c14c32c3963b@app.fastmail.com>
Date: Sun, 16 Nov 2025 13:05:10 +0200
Message-ID: <CAMW7n8CS_bjhd6dKxnabqJVs74CNSG6C4yKSfFgctQ9dwFvndg@mail.gmail.com>
Subject: Re: A Thank you (was Re: [PHP-DEV] PHP True Async RFC Stage 5)
To: Rob Landers <rob@bottled.codes>
Cc: =?UTF-8?Q?Marco_Aur=C3=A9lio_Deleu?= <deleugyn@gmail.com>, 
	Michael Morris <tendoaki@gmail.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)

Hello.

> RFC authors are the subject-matter experts for their proposals, and the w=
ay the process succeeds is by the author being willing to explain, restate,=
 clarify, and anchor concepts for people coming from different backgrounds =
and
> different levels of familiarity.

For the discussion to be constructive, there has to be a shared desire
to reach a common goal.
It sometimes feels like I am the only one who needs asynchrony :)

PHP does not have many options for implementing asynchrony.
Why?

1. Colored functions require the language to support two runtimes. For
PHP this is an anti-pattern. A single unified runtime is the key
feature of the language.
2. Any code with global state inside coroutines will not behave as
expected. This is not a property of this RFC but of any asynchronous
code. I can add this sentence, but last time I was asked to remove
wording that sounded alarming.

True Async, Swoole, and Swow follow the same idea. Different
implementations, but the same logic. AMPHP and React differ only in
that they do not intercept PHP functions, but they still use the same
technology, the same algorithms, and the same approach.

TrueAsync was originally written with code from AMPHP, so you can see
microtasks that AMPHP borrowed from JavaScript. Later, it adopted some
techniques from Swoole.
In other words, PHP has had a de facto coroutine approach for many
years, but no one has ever standardized it. There is an approach and
there are implementations, but there is no RFC.
Do you understand why this RFC is written the way it is?

Why does the RFC state that code does _not need to be changed_?
Because in AMPHP and React you cannot simply take your code and run it
inside a coroutine.
So you must replace all PHP functions with special ones.
This does not mean that a developer should forget about memory or
corner cases. There is no silver bullet in programming.
Do we really need to add a disclaimer under every statement that there
are always exceptions? In programming, every statement has exceptions.

What about colored functions. I recently explored a hybrid approach.
Its logic is relatively simple. The compiler allows writing async next
to a function, and then it automatically infects other functions. At
the same time there is a special word noasync that prevents the
compiler from automatic =E2=80=9Cinfection.=E2=80=9D Something similar can =
be
implemented in PHP using attributes or static analysis. This would
make the code more predictable while keeping it flexible. This RFC
does not conflict with that approach at all, and it can be implemented
in the future if there is a desire to make the language stricter.