Hi
Am 2024-11-05 18:49, schrieb Larry Garfield:
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.
Even though the initial example is one that uses a default parameter
value, we see the primary use case in supporting Closures in attribute
parameters. That’s why that’s the use case mentioned in the first
paragraph and that’s why all the snippets in the “Use Cases” section
showcase attributes.
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.
The extent of investigation I did regarding the implementation was
verifying that “yes, it indeed does crash”, because you can’t build an
implementation if you do not know what the expected behavior should be
in the first place. It is not at all obvious how variable capturing (or
rather: variables in general) should work from a semantic perspective,
as you confirmed yourself (“it’s confusing, and therefore we should
simply disallow it” [1]). We disagree with adding another special-case
to PHP’s semantics by introducing a “non-capturing short closure” as a
third type of Closure [2] and figuring out what the semantics of
variables within const-expr should be is out of scope for this RFC.
In any case, the “Constraints” section already explains why those
constraints exist.
Best regards
Tim Düsterhus
[1] My personal expectation for parameter default values would be that
any previous parameter would be legal to access and capture.
[2] Or fourth, if you consider FCC to be a type of Closure.
