On Mon, Nov 4, 2024, at 6:57 PM, Gina P. Banyard wrote:
> 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.
I suspect, since several people have asked about it, it's because most of 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 method 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-closures and
FCC, not being able to is disappointing, even if the reasons for it 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 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?
I'm not asking for a detailed description of the engine nuances of detecting
unbound variables. Just something along the lines of "this would require
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 future-scopes.
--Larry Garfield
