Hi Tim
śr., 30 paź 2024 o 09:02 Tim Düsterhus <[email protected]> napisał(a):
> Hi
>
> Am 2024-10-30 05:25, schrieb Larry Garfield:
> > This seems like a good idea to me. My only real question is why we
> > need to forbid short-closures. I fully agree that capturing variables
> > for such functions doesn't work. What I don't understand is why that
> > precludes short-closures. Is it not possible to "just" say "there's
> > nothing to even capture in this context, don't try"? (There may be
> > technical reasons for that, but I do not know what they are and the RFC
> > doesn't say.)
>
> It would indeed require some special handling to disable the
> auto-capturing in the code. This would be solvable of course, but
> there's also semantic ambiguity, because users reasonably expect short
> closures to perform auto-capturing:
>
> <?php
>
> $foo = 'foo';
>
> const Closure = static fn (array $bar): array => [$foo, $bar];
>
Personally, I'd expect short-closures be available as well, did you though
about maybe reusing `const` token instead of `static` to make the
information visually available for users?
I mean if PHP could parse `const Closure = const fn (array $bar): array =>
[$foo, $bar];` and the documentation tells that `const` modifier prevent
auto-capture in case of short-closures but also in case of normal closures
to prevent use of use() clause that would be visible instantly in the code.
Consider this syntax as well:
<?php
$foo = '';
const Closure = const function (array $bar): array { return [$foo, $bar]; }
This way we could also forbid use of global-variables, use() clause and
maybe even `static $baz = 1` inside functions. So the closures better match
constant semantics. WDYT?
The engine could create an instance of let's say `\ConstClosure` that would
be a subtype of `\Closure` so it still can be used as a normal closure but
not the other way. Effectively this would make these closures
pure-functions if am not wrong here.
Overall I like the idea.
Cheers,
Michał Marcin Brzuchalski
