Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125883
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 31 Oct 2024 08:22:23 +0100
To: internals@lists.php.net
Message-ID: <c2c5b3d2-46bd-4625-a5dd-13c58c865da8@app.fastmail.com>
In-Reply-To: <fe2230a0-6d1c-4256-8846-ee6de3589451@app.fastmail.com>
References: <15da4c13445d7e9c9d768c60c19768d4@bastelstu.be>
 <3b458165-406c-4b70-97bc-6e98d6c44c72@app.fastmail.com>
 <6f39dce9e6b0579baa51bc84cb8140b9@bastelstu.be>
 <fe2230a0-6d1c-4256-8846-ee6de3589451@app.fastmail.com>
Subject: Re: [PHP-DEV] RFC: Support Closures in constant expressions
Content-Type: multipart/alternative;
 boundary=fc10d1b21f6344c2b1210220d5e6262c
From: rob@bottled.codes ("Rob Landers")

--fc10d1b21f6344c2b1210220d5e6262c
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Oct 31, 2024, at 07:16, Larry Garfield wrote:
> On Wed, Oct 30, 2024, at 3:01 AM, Tim D=C3=BCsterhus 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=20
> >> need to forbid short-closures.  I fully agree that capturing variab=
les=20
> >> for such functions doesn't work.  What I don't understand is why th=
at=20
> >> precludes short-closures.  Is it not possible to "just" say "there'=
s=20
> >> nothing to even capture in this context, don't try"?  (There may be=20
> >> technical reasons for that, but I do not know what they are and the=
 RFC=20
> >> doesn't say.)
> >
> > It would indeed require some special handling to disable the=20
> > auto-capturing in the code. This would be solvable of course, but=20
> > there's also semantic ambiguity, because users reasonably expect sho=
rt=20
> > closures to perform auto-capturing:
> >
> >      <?php
> >
> >      $foo =3D 'foo';
> >
> >      const Closure =3D static fn (array $bar): array =3D> [$foo, $ba=
r];
> >
> >      var_dump((Closure)('bar'));
> >
> > If this would be legal syntax: What would you expect to be printed?
> >
> > Best regards
> > Tim D=C3=BCsterhus
>=20
> Hm.  It would never occur to me to use a function for a non-class cons=
tant in the first place, so I don't know. :-)  Frankly I can't recall th=
e last time I used a non-class constant period. :-)
>=20
> That said, PHP consts are already a bit squishy, and auto-capture is a=
lways by value.  That wouldn't give us a loophole?
>=20
> If it cannot reasonably be done now, but is possible, that should be l=
isted in future scope with roughly what it would take for a follow-up to=
 do.  (And then we can argue if it should just be done now, with more in=
formation as to how much work that is.)
>=20
> --Larry Garfield
>=20

To be honest, I thought it was a rhetorical question since the example i=
s a runtime error (passing string to a function that takes an array), bu=
t on this note, we already know how it should behave: https://3v4l.org/R=
C6b3 because, as you said, it is captured by value. In theory, to suppor=
t this, we would probably need =E2=80=9Clate binding constants=E2=80=9D =
or constants that are executed just before any userland code is run. Sim=
ilar to just emulating it yourself: https://3v4l.org/PMY4W

IMHO, the rules around constant expressions are not sound and feel arbit=
rary when you run into them. They are too easy to work around (though cu=
mbersome) and the code still works, which seems to prove their arbitrary=
 nature.=20

=E2=80=94 Rob
--fc10d1b21f6344c2b1210220d5e6262c
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Thu, Oct 31, 2024, at 07:16, Larry Garfield wrote:<br>=
</div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Wed, Oct 30=
, 2024, at 3:01 AM, Tim D=C3=BCsterhus wrote:<br></div><div>&gt; Hi<br><=
/div><div>&gt;<br></div><div>&gt; Am 2024-10-30 05:25, schrieb Larry Gar=
field:<br></div><div>&gt;&gt; This seems like a good idea to me.&nbsp; M=
y only real question is why we&nbsp;<br></div><div>&gt;&gt; need to forb=
id short-closures.&nbsp; I fully agree that capturing variables&nbsp;<br=
></div><div>&gt;&gt; for such functions doesn't work.&nbsp; What I don't=
 understand is why that&nbsp;<br></div><div>&gt;&gt; precludes short-clo=
sures.&nbsp; Is it not possible to "just" say "there's&nbsp;<br></div><d=
iv>&gt;&gt; nothing to even capture in this context, don't try"?&nbsp; (=
There may be&nbsp;<br></div><div>&gt;&gt; technical reasons for that, bu=
t I do not know what they are and the RFC&nbsp;<br></div><div>&gt;&gt; d=
oesn't say.)<br></div><div>&gt;<br></div><div>&gt; It would indeed requi=
re some special handling to disable the&nbsp;<br></div><div>&gt; auto-ca=
pturing in the code. This would be solvable of course, but&nbsp;<br></di=
v><div>&gt; there's also semantic ambiguity, because users reasonably ex=
pect short&nbsp;<br></div><div>&gt; closures to perform auto-capturing:<=
br></div><div>&gt;<br></div><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;=
?php<br></div><div>&gt;<br></div><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 $foo =3D 'foo';<br></div><div>&gt;<br></div><div>&gt;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; const Closure =3D static fn (array $bar): array =3D&gt; [$f=
oo, $bar];<br></div><div>&gt;<br></div><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; var_dump((Closure)('bar'));<br></div><div>&gt;<br></div><div>&gt;=
 If this would be legal syntax: What would you expect to be printed?<br>=
</div><div>&gt;<br></div><div>&gt; Best regards<br></div><div>&gt; Tim D=
=C3=BCsterhus<br></div><div><br></div><div>Hm.&nbsp; It would never occu=
r to me to use a function for a non-class constant in the first place, s=
o I don't know. :-)&nbsp; Frankly I can't recall the last time I used a =
non-class constant period. :-)<br></div><div><br></div><div>That said, P=
HP consts are already a bit squishy, and auto-capture is always by value=
.&nbsp; That wouldn't give us a loophole?<br></div><div><br></div><div>I=
f it cannot reasonably be done now, but is possible, that should be list=
ed in future scope with roughly what it would take for a follow-up to do=
.&nbsp; (And then we can argue if it should just be done now, with more =
information as to how much work that is.)<br></div><div><br></div><div>-=
-Larry Garfield<br></div><div><br></div></blockquote><div><br></div><div=
>To be honest, I thought it was a rhetorical question since the example =
is a runtime error (passing string to a function that takes an array), b=
ut on this note, we already know how it should behave:&nbsp;<a href=3D"h=
ttps://3v4l.org/RC6b3">https://3v4l.org/RC6b3</a>&nbsp;because, as you s=
aid, it is captured by value. In theory, to support this, we would proba=
bly need =E2=80=9Clate binding constants=E2=80=9D or constants that are =
executed just before any userland code is run. Similar to just emulating=
 it yourself:&nbsp;<a href=3D"https://3v4l.org/PMY4W">https://3v4l.org/P=
MY4W</a><br></div><div><br></div><div>IMHO, the rules around constant ex=
pressions are not sound and feel arbitrary when you run into them. They =
are too easy to work around (though cumbersome) and the code still works=
, which seems to prove their arbitrary nature.&nbsp;</div><div><br></div=
><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--fc10d1b21f6344c2b1210220d5e6262c--