Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125913
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 05 Nov 2024 11:49:40 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <e92efb74-3689-4861-ab9f-9472aecb470e@app.fastmail.com>
In-Reply-To: 
 <2sPXJojAve1IIS8SoHTv2VumjKcVe0iTwygretTEfvf8KVMw_qPZf3vKUfC1GrOk979EvXmKm86igz06Dk6VpOkkMMeU5vYvB4qghjyuk6g=@gpb.moe>
References: <15da4c13445d7e9c9d768c60c19768d4@bastelstu.be>
 <3b458165-406c-4b70-97bc-6e98d6c44c72@app.fastmail.com>
 <6f39dce9e6b0579baa51bc84cb8140b9@bastelstu.be>
 <fe2230a0-6d1c-4256-8846-ee6de3589451@app.fastmail.com>
 <219e4bbc0b94c35d2410fb640db6c477@bastelstu.be>
 <6bffc58a-b869-495e-9be8-0590822e6d79@app.fastmail.com>
 <2sPXJojAve1IIS8SoHTv2VumjKcVe0iTwygretTEfvf8KVMw_qPZf3vKUfC1GrOk979EvXmKm86igz06Dk6VpOkkMMeU5vYvB4qghjyuk6g=@gpb.moe>
Subject: Re: [PHP-DEV] RFC: Support Closures in constant expressions
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Nov 4, 2024, at 6:57 PM, Gina P. Banyard wrote:
> On Monday, 4 November 2024 at 20:32, Larry Garfield=20
> <larry@garfieldtech.com> wrote:
>
>> On Mon, Nov 4, 2024, at 6:06 AM, Tim D=C3=BCsterhus wrote:
>> >=20
>> > Here's another brainteaser:
>> >=20
>> > function foo(
>> > string $bar,
>> > Closure $baz =3D static fn () =3D> $bar,
>> > ) {
>> > var_dump($baz());
>> > }
>> >=20
>> > foo('captured');
>> >=20
>> > What would you expect the semantics of that script to be?
>>=20
>>=20
>> My expectation is that it's confusing, and therefore we should simply=
 disallow it. Which roughly translates to detecting if a closure tries t=
o use an unbound variable statically. Which is probably more difficult t=
han I make it sound. :-)
>
> Which is why short closures are being disallowed.
> The value of it *is* limited, and the semantics of it are confusing.
> I am struggling to see why this is such a big deal.

I suspect, since several people have asked about it, it's because most o=
f the use cases for having a default Closure value are going to be short=
; the sort of short cases that short-closures and FCC are designed for. =
 If it's long, then you're probably better off moving it to a private me=
thod and making a FCC reference to that private method the default value=
 instead.

So if most of the use cases align with where one would use short-closure=
s and FCC, not being able to is disappointing, even if the reasons for i=
t are valid.

>> > > If it cannot reasonably be done now, but is possible, that should=
 be
>> > > listed in future scope with roughly what it would take for a foll=
ow-up
>> > > to do. (And then we can argue if it should just be done now, with=
 more
>> > > information as to how much work that is.)
>> >=20
>> > I have added an entry to the =E2=80=9CFuture Scope=E2=80=9D section=
. See also my reply
>> > to Alex.
>
>> Thanks. Can you include what the implementation challenges are for th=
e future-scope items, to explain why they're being punted to later rathe=
r than addressed now? (As there seems clear interest in having all of th=
em.)
>>=20
>
> I have never seen a future scope section which describes these=20
> challenges, and this feels just giving more work to people for no=20
> benefit?

I'm not asking for a detailed description of the engine nuances of detec=
ting unbound variables.  Just something along the lines of "this would r=
equire detecting unbound variables, that's hard, so we'll save that for =
later."  Which is a level of detail I frequently do provide in my RFC fu=
ture-scopes.

--Larry Garfield