Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125908
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 04 Nov 2024 14:32:11 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <6bffc58a-b869-495e-9be8-0590822e6d79@app.fastmail.com>
In-Reply-To: <219e4bbc0b94c35d2410fb640db6c477@bastelstu.be>
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>
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:06 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2024-10-31 07:16, schrieb Larry Garfield:
>> Hm.  It would never occur to me to use a function for a non-class=20
>> constant in the first place, so I don't know. :-)  Frankly I can't=20
>> recall the last time I used a non-class constant period. :-)
>>=20
>> That said, PHP consts are already a bit squishy, and auto-capture is=20
>> always by value.  That wouldn't give us a loophole?
>
> Here's another brainteaser:
>
>      function foo(
>          string $bar,
>          Closure $baz =3D static fn () =3D> $bar,
>      ) {
>          var_dump($baz());
>      }
>
>      foo('captured');
>
> What would you expect the semantics of that script to be?

My expectation is that it's confusing, and therefore we should simply di=
sallow it.  Which roughly translates to detecting if a closure tries to =
use an unbound variable statically.  Which is probably more difficult th=
an I make it sound. :-)

>> If it cannot reasonably be done now, but is possible, that should be=20
>> listed in future scope with roughly what it would take for a follow-u=
p=20
>> to do.  (And then we can argue if it should just be done now, with mo=
re=20
>> information as to how much work that is.)
>
> I have added an entry to the =E2=80=9CFuture Scope=E2=80=9D section. S=
ee also my reply=20
> to Alex.
>
> Best regards
> Tim D=C3=BCsterhus

Thanks.  Can you include what the implementation challenges are for the =
future-scope items, to explain why they're being punted to later rather =
than addressed now?  (As there seems clear interest in having all of the=
m.)

--Larry Garfield