Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126848
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com>
 <72bd5401-53a9-409f-ad45-687333401961@rwec.co.uk> <CAMW7n8De15X4xDNOBULKeKkpeCeNo-tDWVWZ+Zer8vMa3U-vQg@mail.gmail.com>
 <d50b892b-9372-45c0-81ad-1ce818385b75@rwec.co.uk> <CAMW7n8C16d14earerxvCPe_kyym09GOa8mh4qwPz8AKVKQjHsw@mail.gmail.com>
 <e05cee9d-7901-4b18-b71c-24ad56266534@rwec.co.uk> <CAMW7n8AtLZOof54uJNFG+P4VVwbq65i79x-JDFKPJocDj-w91Q@mail.gmail.com>
 <DBDD7E90-DE94-4A9D-91F2-5CA9E712AE33@rwec.co.uk> <CAMW7n8DYBf73h2maPPcrPAGfEgdEdjeDoYrrD17fmxp9v_gx+g@mail.gmail.com>
 <6987D912-CE46-4145-A8CE-732CA590A522@rwec.co.uk> <CAMW7n8BJcTuTQj_AB4ha-RUF_AY5oKp1y0TaN-+CZOSLpmEoZw@mail.gmail.com>
 <2F013672-9937-4AB1-BC46-86F3D342BE6B@rwec.co.uk>
In-Reply-To: <2F013672-9937-4AB1-BC46-86F3D342BE6B@rwec.co.uk>
Date: Wed, 19 Mar 2025 21:24:43 +0200
Message-ID: <CAMW7n8CmaAFmUVgeJ+Xcxo52yS7O3KjU_LfRx8E6-KZqDxGVEg@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000e6786a0630b6f95e"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000e6786a0630b6f95e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> But even though we're talking in circles about why,
> your latest examples do avoid the particular problem I was trying to
describe.
>
I thought the problem was that the syntax wouldn't work. Is there any other
issue?

>
>  Yes, that would probably be a bad choice as well. Which is why I've
repeatedly suggested a different keyword, and AFAIK you still haven't
actually voiced an opinion on that.
>

Does this concern the syntax of `spawn block {}` or did I miss something?
I will describe the reasons why I rejected the concise syntax in favor of a
more verbose one below.

>
> But you kept referring to that token as "expression", which confused me,
because that's a different thing in the grammar.
>

By the word "expression," I mean a language construct along with keywords.
If `spawn function_call` returns a value, then it can be considered an
expression, right? Or am I mistaken in the terminology?

>
>  I think I asked this before: why would anyone want to specify a return
type there?
>
A simple answer (though not necessarily the correct one): because it=E2=80=
=99s a
closure. And in PHP, a closure has a return type.
I understand what you're asking: what is the practical significance of
this? Perhaps none, but it provides consistency in syntax.

The syntax `spawn {};` is the most elegant in terms of brevity. There's no
doubt that it's shorter by the number of characters in "function".

   - `spawn block {};` also looks decent.  However, the keyword `block`
   does not accurately reflect what is happening, because what follows is n=
ot
   a block but a closure.
   - `spawn closure {};` is a possibility, but it raises the question: why
   introduce the keyword `closure` when we already have `function`? The
   difference in characters is minimal.
   - `spawn fn {};` is the shortest option, but `fn` is already used for
   the shorthand function syntax `fn() =3D> ...`.

But we can forget about `ReturnType`, right? Okay, but there's another
point.

In PHP, code blocks are not all the same.
- `if` / `then` / `else` / `try` / `switch` **do not create a new scope**.
- `function` **does create a new scope**.

When a programmer writes:
```php
$x =3D 5;
spawn {$x++};
```
Will they easily understand that $x++ is not modifying the same $x as
before?
No, they won=E2=80=99t. They will have to remember that spawn {} creates a =
closure,
just like function creates a closure with a separate scope.

This means the programmer has to remember one extra rule. The question is:
is it worth the additional "function" characters?

Though, I don=E2=80=99t mind `spawn fn {};`=E2=80=94this option takes the b=
est of
everything. But if we implement it, I would also introduce the `fn() {}`
syntax.

```
spawn fn use($x) {
    ...
};
```

Apart from violating the language's style, I don't see any drawbacks for
this.

--000000000000e6786a0630b6f95e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;<br>&gt;=C2=A0<span style=3D"background-color:rgb(242,=
242,242);color:rgb(51,51,51);font-family:&quot;Fira Mono&quot;,monospace;fo=
nt-size:14px">But even though we&#39;re talking in circles about why, <br>&=
gt; your latest examples do avoid the=C2=A0</span>particular<span style=3D"=
background-color:rgb(242,242,242);color:rgb(51,51,51);font-family:&quot;Fir=
a Mono&quot;,monospace;font-size:14px"> problem I was trying to describe.</=
span><span style=3D"background-color:rgb(242,242,242);color:rgb(51,51,51);f=
ont-family:&quot;Fira Mono&quot;,monospace;font-size:14px"><br></span>&gt;<=
div>I thought the problem was that the syntax wouldn&#39;t work. Is there a=
ny other issue?=C2=A0=C2=A0</div><div><br></div><div>&gt;<br>&gt;=C2=A0

Yes, that would probably be a bad choice as well. Which is why I&#39;ve rep=
eatedly suggested a different keyword, and AFAIK you still haven&#39;t actu=
ally voiced an opinion on that.<span class=3D"gmail-im" style=3D"color:rgb(=
80,0,80)"><br></span>&gt;</div><div><br></div><div>Does this concern the sy=
ntax of `spawn block {}` or did I miss something?=C2=A0=C2=A0<br></div><div=
>I will describe the reasons why I rejected the concise syntax in favor of =
a more verbose one below.=C2=A0=C2=A0<br></div><div><br></div><div>&gt;=C2=
=A0<br>&gt; But you kept referring to that token as &quot;expression&quot;,=
 which confused me, because that&#39;s a different thing in the grammar.</d=
iv><div>&gt;</div><div><br></div><div>By the word &quot;expression,&quot; I=
 mean a language construct along with keywords.=C2=A0</div><div>If `spawn f=
unction_call` returns a value, then it can be considered an expression, rig=
ht? Or am I mistaken in the terminology?<br></div><div><br></div><div>&gt;<=
br>&gt;=C2=A0

I think I asked this before: why would anyone want to specify a return type=
 there?<br>&gt;</div><div>A simple answer (though not necessarily the corre=
ct one): because it=E2=80=99s a closure. And in PHP, a closure has a return=
 type. =C2=A0<br>I understand what you&#39;re asking: what is the practical=
 significance of this? Perhaps none, but it provides consistency in syntax.=
=C2=A0</div><div><br></div><div>The syntax `spawn {};` is the most elegant =
in terms of brevity. There&#39;s no doubt that it&#39;s shorter by the numb=
er of characters in &quot;function&quot;.=C2=A0=C2=A0<br></div><div><ul><li=
>`spawn block {};` also looks decent.=C2=A0 However, the keyword `block` do=
es not accurately reflect what is happening, because what follows is not a =
block but a closure.=C2=A0=C2=A0</li><li>`spawn closure {};` is a possibili=
ty, but it raises the question: why introduce the keyword `closure` when we=
 already have `function`? The difference in characters is minimal.=C2=A0=C2=
=A0</li><li>`spawn fn {};` is the shortest option, but `fn` is already used=
 for the shorthand function syntax `fn() =3D&gt; ...`.=C2=A0=C2=A0</li></ul=
><div>But we can forget about `ReturnType`, right? Okay, but there&#39;s an=
other point.<br></div><br>In PHP, code blocks are not all the same. =C2=A0<=
br>- `if` / `then` / `else` / `try` / `switch` **do not create a new scope*=
*. =C2=A0<br>- `function` **does create a new scope**. =C2=A0<br><br>When a=
 programmer writes: =C2=A0<br>```php<br>$x =3D 5;<br>spawn {$x++};<br></div=
><div>```</div><div>Will they easily understand that <code>$x++</code> is n=
ot modifying the same <code>$x</code> as before?<br>
No, they won=E2=80=99t. They will have to remember that <code>spawn {}</cod=
e> creates a closure, just like <code>function</code> creates a closure wit=
h a separate scope.=C2=A0</div><div><br></div><div>This means the programme=
r has to remember one extra rule. The question is: is it worth the addition=
al &quot;function&quot; characters? =C2=A0<br><br>Though, I don=E2=80=99t m=
ind `spawn fn {};`=E2=80=94this option takes the best of everything. But if=
 we implement it, I would also introduce the `fn() {}` syntax.=C2=A0=C2=A0<=
br></div><div><br></div><div>```</div><div>spawn fn use($x) {<br>=C2=A0 =C2=
=A0 ...<br>};</div><div>```</div><div><br></div><div>Apart from violating t=
he language&#39;s style, I don&#39;t see any drawbacks for this.=C2=A0=C2=
=A0<br></div></div>

--000000000000e6786a0630b6f95e--