On Monday, 4 November 2024 at 20:32, Larry Garfield <la...@garfieldtech.com>
wrote:
> On Mon, Nov 4, 2024, at 6:06 AM, Tim Düsterhus wrote:
> >
> > Here's another brainteaser:
> >
> > function foo(
> > string $bar,
> > Closure $baz = static fn () => $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
> disallow it. Which roughly translates to detecting if a closure tries to use
> an 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 just
hella confusing, banning it for all is clear and easy to reason about.
>
> > > 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-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.)
> >
> > I have added an entry to the “Future Scope” section. See also my reply
> > to Alex.
> 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 them.)
>
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 were
split out because they are different scopes.
It is *fine* to have smaller incremental RFCs that build on top of each other
without needing to provide justification as to why it was punted to later.
Arguably, the onus should be on people wanting it to be in the RFC to do the
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
