Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128836
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 14 Oct 2025 08:32:57 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <d4c99ddc-d62f-4574-a798-80fa7b1d3e1c@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8BG=GsqrQ-D6rekRgYOg0y_SUJksio7Y-uQKSs97zixEg@mail.gmail.com>
References: 
 <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <CADuktwNP+t-DJbLCsnHHhztZYmOMGYde9rzNm+9B0SUsrNvV-g@mail.gmail.com>
 <CAMW7n8BTb1OHdLsjD+fPyeGOkYSQx-KXMrLnG-4rVUSq2646+Q@mail.gmail.com>
 <14f591d4-aa1e-49dc-bc20-03cb493dc20c@app.fastmail.com>
 <CAMW7n8C6vSxSEiA=5zntf4Yu9H1yPE+LrG_SZns7YA1Lxim1oA@mail.gmail.com>
 <CADK1yX+0+Nu9Srqe0CYmDmFWfxRoVrDy=bDnHg6YTmNTwKKtnA@mail.gmail.com>
 <CAMW7n8BWvf-bE6g7A_0vDW1Lf8hhTm-zuyNEY23DA0biNS-YSA@mail.gmail.com>
 <c2aa62a2-da4b-4caa-99b3-e286ca5ced76@app.fastmail.com>
 <4f9b8dfd-5415-3df3-fda9-33a8716c57c1@php.net>
 <CAMW7n8BG=GsqrQ-D6rekRgYOg0y_SUJksio7Y-uQKSs97zixEg@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 Tue, Oct 14, 2025, at 1:32 AM, Edmond Dantes wrote:
> Hello.
>
>> I tried reading the RFC today, but I ran out of time. It is *59* page=
 printed (I didn't).
> ...
>> I don't think the RFC as-is is close to this at all =E2=80=94 but I h=
ave mostly skimmed it so far.
>
> **Thank you for the feedback.**
>
> This time there will be a vote. If this RFC is not accepted, I promise
> that I will not create a fifth version. So if anyone has something to
> say, please feel free to speak openly. Please.

Like Derick, I am still highly skeptical about this design.  It's vastly=
 improved from the first version back in the spring, but there are still=
 numerous footguns in the design that will lead me to voting No on its c=
urrent iteration.  Mainly, we should not be allowing anything but struct=
ured, guaranteed async blocks (as described in the article Derick linked=
).  It is still perfectly possible to build completely-async systems tha=
t way, but it prevents writing code that would only work in such an all-=
encompassing system.

I very much want to see it evolve further in that direction before a vot=
e is called and we're locked into a system with so many foot guns built =
in.

--Larry Garfield