Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129452
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 25 Nov 2025 12:50:49 +0100
To: internals@lists.php.net
Message-ID: <1a31ee0e-cbfd-49df-baa6-99d27ae45fc4@app.fastmail.com>
In-Reply-To: 
 <CAB9bCb0R4dt4g6Ed6XKAh9HU-8=dMqiyw1j71-M-z9Lu2=uU6A@mail.gmail.com>
References: 
 <CAMW7n8Dogjj2JFJBNArk-BfvOHRqHKMAFReXJAhDm2UPV1TF7A@mail.gmail.com>
 <92865666.4510.1763818506332@email.ionos.de>
 <CAMW7n8AycfX4NMfjJ+GzFsPqRaSae-t7Cm3H5z8apRzXUgaVZw@mail.gmail.com>
 <329450798.8037.1763822426377@email.ionos.de>
 <CAMW7n8DTt2S_RfcyshERixed=qqyFUPEvWp_MpgpW_CvH3urXQ@mail.gmail.com>
 <CAMW7n8CUQxqh4_rTWQBcj+t17i5oW7x-V96FSkwZL85Z2pzrRw@mail.gmail.com>
 <CAB9bCb34cmu9=an9K4rubPSVEDwyWH-rMAVtTTYa3U-LA+GJ+A@mail.gmail.com>
 <CAMW7n8DM4MCP25gSLBbd3+Awzs2+p6Qs_jPgx1mk=RjSVe+iUw@mail.gmail.com>
 <9287c46c-bc63-4dd0-9792-0f9421959589@rwec.co.uk>
 <CAMW7n8AhbBawCBtfNJZ6XzFSvwhtZotfgBmb1O4CDZ+J2jxt2w@mail.gmail.com>
 <C766271D-EE7A-4727-8A7C-B117429768E5@rwec.co.uk>
 <CAMW7n8Bk+AhbXjg8QADFo=2k9qCE54DD68Hxkf2k_9J=EFboUQ@mail.gmail.com>
 <65869feb-d518-4de3-8c10-115e3ba7dce7@rwec.co.uk>
 <CAMW7n8CA6gfdWzhVCY3j4w_=S-rZW5sUvkSL_e4+hc_Ka+r1rA@mail.gmail.com>
 <55149f3e-7ec7-4479-bd6d-2e7fe1b8edef@rwec.co.uk>
 <CAMW7n8Cfs9+wEpGVp5C2VL3ey8vKUNS2NyJAq+w7-DJXg172Dw@mail.gmail.com>
 <19693420-c091-49b7-b557-e09717239d9b@rwec.co.uk>
 <CAMW7n8DUGhai5v95_5Nv6Vxuj1CuhmnFOVnAPVW2ao37agQkzw@mail.gmail.com>
 <c9d5cc10-9605-45ee-9d06-9a66de4d71a2@app.fastmail.com>
 <CAB9bCb0R4dt4g6Ed6XKAh9HU-8=dMqiyw1j71-M-z9Lu2=uU6A@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
Content-Type: multipart/alternative;
 boundary=538cafc5c80b4b3bb6e1ca2b0a0c54f8
From: rob@bottled.codes ("Rob Landers")

--538cafc5c80b4b3bb6e1ca2b0a0c54f8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Nov 25, 2025, at 12:03, Bart Vanhoutte wrote:
> Op di 25 nov 2025 om 11:36 schreef Rob Landers <rob@bottled.codes>:
> >
> >
> > If we're going to have to recreate some of the most basic interfaces=
 to get async to work ... does it make sense to seriously consider colou=
red functions? As annoying as it would be to refactor so much code, I th=
ink we could realistically provide ourselves escape hatches by not requi=
ring every function calling `await` to be async?
> >
>=20
> I have worked with coloured functions in PHP when Fibers were not
> around and the developer experience is very bad. Before PHP 8.1; every
> function I wrote would be coloured by either accepting or returning a
> Promise<sometype> (which is made worse by the fact there's no
> generics).
>=20
> Since PHP 8.1; I can use Fibers and implement a widely spread
> Interface in an async way. Currently, if I want to use an SDK client,
> the first thing that I check is `composer.json` to find out what HTTP
> client it uses. If it accepts a PSR-18 ClientInterface I use a small
> wrapper around ReactPHP's Browser that awaits a Promise and I'm set.
> We've been talking about shared state and possible breaks in backwards
> compatibility, but I must say that in reality it's not something that
> I find being in the way very often. Like I've made it seem before, if
> there's any serious breaks in backward compatibility (not the order of
> log lines that might be different from the sync implementation) I
> would at that point just document the change and release a new major
> version of a library. That is a lot less painful imo than working with
> coloured functions.
>=20
> Best Regards,
> Bart

Looking higher up the thread, you'll see that Larry also proposed someth=
ing similar. I'm not saying everything needs to be coloured.

In other words, there is no "Promise" object that always needs to be han=
dled. Adding an "async" to the function makes it return a Coroutine, tha=
t can be awaited. This is a bit different than Generators where you can =
only return a Generator. The return type stays as you'd expect it to be =
if it weren't async.

Then, when/if you call await on this coroutine, and we're not already in=
 a coroutine, it will spawn one for us, blocking until it returns. If we=
 are already inside a coroutine, then it blocks until the coroutine comp=
letes.

Then you have coloured functions when you want them, but can call them w=
ithout having to change your code or "infect" your code with async/await=
. Its literally just sugar over the currently proposed RFC, as you'd hav=
e to return Coroutines and await them anyway, but this is actually more =
type-safe.

=E2=80=94 Rob
--538cafc5c80b4b3bb6e1ca2b0a0c54f8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Tue, Nov 25, 2025, at 12:03, Bart Vanhoutte wrote:<=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Op di 25 nov 20=
25 om 11:36 schreef Rob Landers &lt;<a href=3D"mailto:rob@bottled.codes"=
>rob@bottled.codes</a>&gt;:</div><div>&gt;</div><div>&gt;</div><div>&gt;=
 If we're going to have to recreate some of the most basic interfaces to=
 get async to work ... does it make sense to seriously consider coloured=
 functions? As annoying as it would be to refactor so much code, I think=
 we could realistically provide ourselves escape hatches by not requirin=
g every function calling `await` to be async?</div><div>&gt;</div><div><=
br></div><div>I have worked with coloured functions in PHP when Fibers w=
ere not</div><div>around and the developer experience is very bad. Befor=
e PHP 8.1; every</div><div>function I wrote would be coloured by either =
accepting or returning a</div><div>Promise&lt;sometype&gt; (which is mad=
e worse by the fact there's no</div><div>generics).</div><div><br></div>=
<div>Since PHP 8.1; I can use Fibers and implement a widely spread</div>=
<div>Interface in an async way. Currently, if I want to use an SDK clien=
t,</div><div>the first thing that I check is `<a href=3D"http://composer=
.json">composer.json</a>` to find out what HTTP</div><div>client it uses=
. If it accepts a PSR-18 ClientInterface I use a small</div><div>wrapper=
 around ReactPHP's Browser that awaits a Promise and I'm set.</div><div>=
We've been talking about shared state and possible breaks in backwards</=
div><div>compatibility, but I must say that in reality it's not somethin=
g that</div><div>I find being in the way very often. Like I've made it s=
eem before, if</div><div>there's any serious breaks in backward compatib=
ility (not the order of</div><div>log lines that might be different from=
 the sync implementation) I</div><div>would at that point just document =
the change and release a new major</div><div>version of a library. That =
is a lot less painful imo than working with</div><div>coloured functions=
.</div><div><br></div><div>Best Regards,</div><div>Bart</div></blockquot=
e><div><br></div><div>Looking higher up the thread, you'll see that Larr=
y also proposed something similar. I'm not saying everything needs to be=
 coloured.</div><div><br></div><div>In other words, there is no "Promise=
" object that always needs to be handled. Adding an "async" to the funct=
ion makes it return a Coroutine, that can be awaited. This is a bit diff=
erent than Generators where you can only return a Generator. The return =
type stays as you'd expect it to be if it weren't async.</div><div><br><=
/div><div>Then, when/if you call await on this coroutine, and we're not =
already in a coroutine, it will spawn one for us, blocking until it retu=
rns. If we are already inside a coroutine, then it blocks until the coro=
utine completes.</div><div><br></div><div>Then you have coloured functio=
ns when you want them, but can call them without having to change your c=
ode or "infect" your code with async/await. Its literally just sugar ove=
r the currently proposed RFC, as you'd have to return Coroutines and awa=
it them anyway, but this is actually more type-safe.<br></div><div><br><=
/div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--538cafc5c80b4b3bb6e1ca2b0a0c54f8--