Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129450
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 25 Nov 2025 11:33:14 +0100
To: "Edmond Dantes" <edmond.ht@gmail.com>,
 "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Message-ID: <c9d5cc10-9605-45ee-9d06-9a66de4d71a2@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8DUGhai5v95_5Nv6Vxuj1CuhmnFOVnAPVW2ao37agQkzw@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>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
Content-Type: multipart/alternative;
 boundary=f8f67c73596641438776e6f0e2177e73
From: rob@bottled.codes ("Rob Landers")

--f8f67c73596641438776e6f0e2177e73
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 25, 2025, at 10:40, Edmond Dantes wrote:
> Hello
>=20
> > Susie doesn't know anything about the implementation, other than wha=
t is defined in the interface. That is literally the purpose of acceptin=
g an interface.
> > So it sounds like her only safe option is to restrict her usage of a=
sync coroutines to small self-contained pieces of code, and only use inj=
ected dependencies and callbacks in the "main" coroutine where they were=
 passed in.
>=20
> Exactly. This means that for asynchronous logging, a separate
> interface must be introduced in order to guarantee correct behavior.

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 requiring=
 every function calling `await` to be async?

// non-async functions can still call await, but this just forces a bloc=
king call to the async function
function i_call_await(): string {
  return await someAsyncFunction(); // spawns and blocks until a corouti=
ne completes
}

// returns Coroutine<string> -- since we don't have generics
async function someAsyncFunction(): string {
  return file_get_contents_async('some_file'); // does not block but ret=
urns a coroutine since the function is async
}

// alternative implementation that technically returns CompletedCoroutin=
e<string>
async function someAsyncFunction(): string {
  return await file_get_contents_async('some_file'); // spawns and block=
s until a coroutine completes
}

Just a thought and would mostly just be sugar around the proposed RFC.

=E2=80=94 Rob
--f8f67c73596641438776e6f0e2177e73
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Tue, Nov =
25, 2025, at 10:40, Edmond Dantes wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>Hello</div><div><br></div><div>&gt; Susie does=
n't know anything about the implementation, other than what is defined i=
n the interface. That is literally the purpose of accepting an interface=
.</div><div>&gt; So it sounds like her only safe option is to restrict h=
er usage of async coroutines to small self-contained pieces of code, and=
 only use injected dependencies and callbacks in the "main" coroutine wh=
ere they were passed in.</div><div><br></div><div>Exactly. This means th=
at for asynchronous logging, a separate</div><div>interface must be intr=
oduced in order to guarantee correct behavior.<br></div></blockquote><di=
v><br></div><div>If we're going to have to recreate some of the most bas=
ic interfaces to get async to work ... does it make sense to seriously c=
onsider coloured functions? As annoying as it would be to refactor so mu=
ch code, I think we could realistically provide ourselves escape hatches=
 by not requiring every function calling `await` to be async?</div><div>=
<br></div><div>// non-async functions can still call await, but this jus=
t forces a blocking call to the async function</div><div>function i_call=
_await(): string {</div><div>&nbsp; return await someAsyncFunction(); //=
 spawns and blocks until a coroutine completes</div><div>}</div><div><br=
></div><div>// returns Coroutine&lt;string&gt; -- since we don't have ge=
nerics</div><div>async function someAsyncFunction(): string {</div><div>=
&nbsp; return file_get_contents_async('some_file'); // does not block bu=
t returns a coroutine since the function is async</div><div>}</div><div>=
<br></div><div>// alternative implementation that technically returns Co=
mpletedCoroutine&lt;string&gt;</div><div>async function someAsyncFunctio=
n(): string {</div><div>&nbsp; return await file_get_contents_async('som=
e_file'); // spawns and blocks until a coroutine completes</div><div>}</=
div><div><br></div><div>Just a thought and would mostly just be sugar ar=
ound the proposed RFC.<br></div><div><br></div><div id=3D"sig121229152">=
=E2=80=94 Rob</div></body></html>
--f8f67c73596641438776e6f0e2177e73--