Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125878
Precedence: bulk
MIME-Version: 1.0
References: <15da4c13445d7e9c9d768c60c19768d4@bastelstu.be>
 <3b458165-406c-4b70-97bc-6e98d6c44c72@app.fastmail.com> <6f39dce9e6b0579baa51bc84cb8140b9@bastelstu.be>
In-Reply-To: <6f39dce9e6b0579baa51bc84cb8140b9@bastelstu.be>
Date: Wed, 30 Oct 2024 10:58:59 +0100
Message-ID: <CABdc3WpqHq9hYX9cVxG2r-6xESiC+RqAL+O0qg6SqMo1xqOBhg@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: Support Closures in constant expressions
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000db1b470625aec0b5"
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--000000000000db1b470625aec0b5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tim

=C5=9Br., 30 pa=C5=BA 2024 o 09:02 Tim D=C3=BCsterhus <tim@bastelstu.be> na=
pisa=C5=82(a):

> Hi
>
> Am 2024-10-30 05:25, schrieb Larry Garfield:
> > This seems like a good idea to me.  My only real question is why we
> > need to forbid short-closures.  I fully agree that capturing variables
> > for such functions doesn't work.  What I don't understand is why that
> > precludes short-closures.  Is it not possible to "just" say "there's
> > nothing to even capture in this context, don't try"?  (There may be
> > technical reasons for that, but I do not know what they are and the RFC
> > doesn't say.)
>
> It would indeed require some special handling to disable the
> auto-capturing in the code. This would be solvable of course, but
> there's also semantic ambiguity, because users reasonably expect short
> closures to perform auto-capturing:
>
>      <?php
>
>      $foo =3D 'foo';
>
>      const Closure =3D static fn (array $bar): array =3D> [$foo, $bar];
>

Personally, I'd expect short-closures be available as well, did you though
about maybe reusing `const` token instead of `static` to make the
information visually available for users?

I mean if PHP could parse `const Closure =3D const fn (array $bar): array =
=3D>
[$foo, $bar];` and the documentation tells that `const` modifier prevent
auto-capture in case of short-closures but also in case of normal closures
to prevent use of use() clause that would be visible instantly in the code.

Consider this syntax as well:

<?php

$foo =3D '';

const Closure =3D const function (array $bar): array { return [$foo, $bar];=
 }

This way we could also forbid use of global-variables, use() clause and
maybe even `static $baz =3D 1` inside functions. So the closures better mat=
ch
constant semantics. WDYT?

The engine could create an instance of let's say `\ConstClosure` that would
be a subtype of `\Closure` so it still can be used as a normal closure but
not the other way. Effectively this would make these closures
pure-functions if am not wrong here.

Overall I like the idea.

Cheers,
Micha=C5=82 Marcin Brzuchalski

--000000000000db1b470625aec0b5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Tim</div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">=C5=9Br., 30 pa=C5=BA 2024 o 09:02=
=C2=A0Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@bastel=
stu.be</a>&gt; napisa=C5=82(a):<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">Hi<br>
<br>
Am 2024-10-30 05:25, schrieb Larry Garfield:<br>
&gt; This seems like a good idea to me.=C2=A0 My only real question is why =
we <br>
&gt; need to forbid short-closures.=C2=A0 I fully agree that capturing vari=
ables <br>
&gt; for such functions doesn&#39;t work.=C2=A0 What I don&#39;t understand=
 is why that <br>
&gt; precludes short-closures.=C2=A0 Is it not possible to &quot;just&quot;=
 say &quot;there&#39;s <br>
&gt; nothing to even capture in this context, don&#39;t try&quot;?=C2=A0 (T=
here may be <br>
&gt; technical reasons for that, but I do not know what they are and the RF=
C <br>
&gt; doesn&#39;t say.)<br>
<br>
It would indeed require some special handling to disable the <br>
auto-capturing in the code. This would be solvable of course, but <br>
there&#39;s also semantic ambiguity, because users reasonably expect short =
<br>
closures to perform auto-capturing:<br>
<br>
=C2=A0 =C2=A0 =C2=A0&lt;?php<br>
<br>
=C2=A0 =C2=A0 =C2=A0$foo =3D &#39;foo&#39;;<br>
<br>
=C2=A0 =C2=A0 =C2=A0const Closure =3D static fn (array $bar): array =3D&gt;=
 [$foo, $bar];<br></blockquote><div><br></div><div>Personally, I&#39;d expe=
ct short-closures be available as well, did you though about maybe reusing =
`const` token instead of `static` to make the information visually availabl=
e for users?</div><div><br></div><div>I mean if PHP could parse `const Clos=
ure =3D const fn (array $bar): array =3D&gt; [$foo, $bar];` and the documen=
tation tells that `const` modifier prevent auto-capture in case of short-cl=
osures but also in case of normal closures to prevent use of use() clause t=
hat would be visible instantly in the code.</div><div><br></div><div>Consid=
er this syntax as well:</div><div><br></div><div>&lt;?php</div><div><br></d=
iv><div>$foo =3D &#39;&#39;;</div><div><br></div><div>const Closure =3D con=
st function (array $bar): array { return [$foo, $bar]; }</div><div><br></di=
v><div>This way we could also forbid use of global-variables, use() clause =
and maybe even `static $baz =3D 1` inside functions. So the closures better=
 match constant semantics. WDYT?=C2=A0</div><div><br></div><div>The engine =
could create an instance of let&#39;s say `\ConstClosure` that would be a s=
ubtype of `\Closure` so it still can be used as a normal closure but not th=
e other way. Effectively this would make these closures pure-functions if a=
m not wrong here.</div><div><br></div><div>Overall I like the idea.</div><d=
iv><br></div><div>Cheers,</div><div>Micha=C5=82 Marcin Brzuchalski</div></d=
iv></div>

--000000000000db1b470625aec0b5--