Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125909
Date: Tue, 05 Nov 2024 00:57:04 +0000
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] RFC: Support Closures in constant expressions
Message-ID: <2sPXJojAve1IIS8SoHTv2VumjKcVe0iTwygretTEfvf8KVMw_qPZf3vKUfC1GrOk979EvXmKm86igz06Dk6VpOkkMMeU5vYvB4qghjyuk6g=@gpb.moe>
In-Reply-To: <6bffc58a-b869-495e-9be8-0590822e6d79@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> <219e4bbc0b94c35d2410fb640db6c477@bastelstu.be> <6bffc58a-b869-495e-9be8-0590822e6d79@app.fastmail.com>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Monday, 4 November 2024 at 20:32, Larry Garfield <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 dis=
allow it. Which roughly translates to detecting if a closure tries to use a=
n unbound variable statically. Which is probably more difficult than 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.
You know very well that PHP has tricky semantics that make figuring out "is=
 this case ok but not this" near impossible.
Moreover, having short closure work in *some* but not *all* cases is also j=
ust hella confusing, banning it for all is clear and easy to reason about.

>=20
> > > 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 follow-u=
p
> > > to do. (And then we can argue if it should just be done now, with mor=
e
> > > information as to how much work that is.)
> >=20
> > I have added an entry to the =E2=80=9CFuture Scope=E2=80=9D section. Se=
e also my reply
> > to Alex.

> Thanks. Can you include what the implementation challenges are for the fu=
ture-scope items, to explain why they're being punted to later rather than =
addressed now? (As there seems clear interest in having all of them.)
>=20

I have never seen a future scope section which describes these challenges, =
and this feels just giving more work to people for no benefit?
There has been clear intent on having Pattern matching and ADTs, yet they w=
ere split out because they are different scopes.
It is *fine* to have smaller incremental RFCs that build on top of each oth=
er without needing to provide justification as to why it was punted to late=
r.
Arguably, the onus should be on people wanting it to be in the RFC to do th=
e research and provide some implementation idea to have them be one RFC for=
 this discussion to be at all reasonable.

Best regards,

Gina P. Banyard