Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128848
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 16 Oct 2025 09:18:23 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: internals@lists.php.net
Message-ID: <ad8ed020-6bab-47da-ba66-9da95484c92a@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8BpUHHVmbWByHAsZUYhZimv5M=tSGJJQLRJR8iUfO96-w@mail.gmail.com>
References: 
 <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <bcd8253c-04f3-4046-b51f-2e387e215f6d@app.fastmail.com>
 <CAMW7n8BfP7h5rpDrjigu0oWK4Z+aRaqGjgzEFS_mDXRhq19vQQ@mail.gmail.com>
 <2b9fd3ec-50ca-41e4-985a-274f886df8b3@app.fastmail.com>
 <CAMW7n8C5GD+F2KdCZTtZwFbc2rk_4yGgdiak8fs9y5Z3UU_zxg@mail.gmail.com>
 <2e39e211-c816-41db-a079-f2c6b3934e0a@app.fastmail.com>
 <CAMW7n8BpUHHVmbWByHAsZUYhZimv5M=tSGJJQLRJR8iUfO96-w@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=f2c82169b5de4e089215d289e96dba12
From: rob@bottled.codes ("Rob Landers")

--f2c82169b5de4e089215d289e96dba12
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 16, 2025, at 09:08, Edmond Dantes wrote:
> > I would expect more than "because I said so"
>=20
> In my response I provided arguments, but they were ignored. If you
> tell me exactly what is unclear to you, I can give a concrete,
> well-reasoned answer.
>=20

This is all I have to go off of, and my explicit rebuttals as to why the=
y are not reasons:

> Therefore, if a `Scope` needs to be awaited, it can only be done
> together with a cancellation token.

This is effectively not true. I can pass a cancellation token that never=
 cancels. Sometimes, this is exactly the behaviour that is desired.

> In real-world scenarios, awaiting a `Scope` during normal execution
> makes no sense, because you have a `cancellation policy`.
> This means that at any necessary moment you can dispose() the `Scope`
> and thus interrupt the execution of tasks inside the black box.

That sounds like a feature, not a reason.

> For the `TaskGroup` pattern, which exists in the third version of the
> RFC, awaiting is a relatively safe operation, because in this case we
> assume that the code is written by someone who has direct access to
> the agreements and bears full responsibility for any errors.

We aren't talking about TaskGroups, but regardless, I fail to understand=
 how that makes scopes 'dangerous' to await and why it should not be Awa=
itable.

> So, `Scope` is intended for components where responsibility is shared
> between different programmers, while `TaskGroup` should be used when
> working with a clearly defined set of coroutines.

My question is "why does this mean something with an await method isn't =
Awaitable?" -- it seems that this is orthogonal to the interface and the=
 reason why it should/should not be Awaitable.

=E2=80=94 Rob
--f2c82169b5de4e089215d289e96dba12
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Thu, Oct =
16, 2025, at 09:08, Edmond Dantes wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>&gt; I would expect more than "because I said =
so"</div><div><br></div><div>In my response I provided arguments, but th=
ey were ignored. If you</div><div>tell me exactly what is unclear to you=
, I can give a concrete,</div><div>well-reasoned answer.</div><div><br><=
/div></blockquote><div><br></div><div>This is all I have to go off of, a=
nd my explicit rebuttals as to why they are not reasons:</div><div><br><=
/div><blockquote type=3D"cite"><div>Therefore, if a `Scope` needs to be =
awaited, it can only be done</div><div>together with a cancellation toke=
n.</div></blockquote><div><br></div><div>This is effectively not true. I=
 can pass a cancellation token that never cancels. Sometimes, this is ex=
actly the behaviour that is desired.</div><div><br></div><blockquote typ=
e=3D"cite"><div>In real-world scenarios, awaiting a `Scope` during norma=
l execution</div><div>makes no sense, because you have a `cancellation p=
olicy`.</div><div>This means that at any necessary moment you can dispos=
e() the `Scope`</div><div>and thus interrupt the execution of tasks insi=
de the black box.</div></blockquote><div><br></div><div>That sounds like=
 a feature, not a reason.</div><div><br></div><blockquote type=3D"cite">=
<div>For the `TaskGroup` pattern, which exists in the third version of t=
he</div><div>RFC, awaiting is a relatively safe operation, because in th=
is case we</div><div>assume that the code is written by someone who has =
direct access to</div><div>the agreements and bears full responsibility =
for any errors.</div></blockquote><div><br></div><div>We aren't talking =
about TaskGroups, but regardless, I fail to understand how that makes sc=
opes 'dangerous' to await and why it should not be Awaitable.</div><div>=
<br></div><blockquote type=3D"cite"><div>So, `Scope` is intended for com=
ponents where responsibility is shared</div><div>between different progr=
ammers, while `TaskGroup` should be used when</div><div>working with a c=
learly defined set of coroutines.</div></blockquote><div><br></div><div>=
My question is "why does this mean something with an await method isn't =
Awaitable?" -- it seems that this is orthogonal to the interface and the=
 reason why it should/should not be Awaitable.</div><div><br></div><div =
id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--f2c82169b5de4e089215d289e96dba12--