Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125877
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:31:03 +0200
Message-ID: <CAAwdEzBV1G=xVxHqyu5QSt_G+Fx+Pf_g-zGasLzJfFKkGpM=EA@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="000000000000b659540625ad8662"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000b659540625ad8662
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 30, 2024 at 10:03=E2=80=AFAM Tim D=C3=BCsterhus <tim@bastelstu.=
be> wrote:

> 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:
>
>
Hi Tim,

So, why not allow capturing, since anyway the only place to capture are
constants and static variables?
And this way we could have short closures with auto-capture.
If there are some technical reasons for not doing that, can we have written
in the RFC?

Alex

--000000000000b659540625ad8662
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 30, 2024 at 10:03=E2=80=AFAM =
Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@bastelstu.be=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-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></blockquote><div><br></div><div=
>Hi Tim,</div><div><br></div><div>So, why not allow capturing, since anyway=
 the only place to capture are constants and static variables?</div><div>An=
d this way we could have short closures with auto-capture.</div><div>If the=
re are some technical reasons for not doing that, can we have=C2=A0written =
in the RFC?</div><div><br></div><div>Alex</div><div>=C2=A0=C2=A0</div></div=
></div>

--000000000000b659540625ad8662--