Hi everyone
As foreshadowed, I opened the vote for the closure optimizations RFC.
RFC: https://wiki.php.net/rfc/closure-optimizations
PR: https://github.com/php/php-src/pull/19941
Discussion: https://news-web.php.net/php.internals/129957
Original announcement: https://news-web.php.net/php.internals/129825
The vote will end on 2026-03-13 14:00 UTC.
Ilija
Hi everyone
As foreshadowed, I opened the vote for the closure optimizations RFC.
RFC: https://wiki.php.net/rfc/closure-optimizations
PR: https://github.com/php/php-src/pull/19941
Discussion: https://news-web.php.net/php.internals/129957
Original announcement: https://news-web.php.net/php.internals/129825The vote will end on 2026-03-13 14:00 UTC.
Ilija
Is there any benefit for projects that already mark all static
closures with the keyword "static"?
One thing I am worried about is that people may think the RFC removes
the need for that keyword, which it looks like it doesn't. Not only
can your patch not infer 100% of static closures, but it also doesn't
prevent accidentally using $this in a closure that was supposed to be
static.
Hi Kamil
As foreshadowed, I opened the vote for the closure optimizations RFC.
Is there any benefit for projects that already mark all static
closures with the keyword "static"?
Yes. The caching of stateless closures is what brings most of the
performance benefits. Static closure inference enables this
optimization in more cases, namely in codebases that don't explicitly
want to add static for whatever reason.
One thing I am worried about is that people may think the RFC removes
the need for that keyword, which it looks like it doesn't. Not only
can your patch not infer 100% of static closures, but it also doesn't
prevent accidentally using $this in a closure that was supposed to be
static.
The RFC is explicit about static not being redundant.
While explicit marking remains preferable, this optimization aims to benefit codebases that prefer not to add static to avoid visual clutter, as well as those who aren't aware of these subtle performance implications.
Ilija
Hi everyone
RFC: https://wiki.php.net/rfc/closure-optimizations
The vote will end on 2026-03-13 14:00 UTC.
The vote has now closed. The RFC was accepted with 24 Yes, 0 No and 1
Abstain votes.
Thank you for participating.
Ilija
Hi everyone
RFC: https://wiki.php.net/rfc/closure-optimizations
The vote will end on 2026-03-13 14:00 UTC.
The vote has now closed. The RFC was accepted with 24 Yes, 0 No and 1
Abstain votes.
Thank you for participating.
A very late update on this RFC. Sadly, some edge cases were discovered
with regards to static closure inference.
Consider:
class Foo {
public function instanceCall() {
return $this;
}
public function test($c) {
return (function () use ($c) {
return array_map($c, [1]);
})();
}
}
$foo = new Foo();
var_dump($foo->test('Foo::instanceCall'));
// array(1) {
// [0]=>
// object(Foo)#1 (0) {
// }
// }
The closure within test() violates none of the rules from
https://wiki.php.net/rfc/closure-optimizations#static_closure_inference,
yet performs an instance call. I failed to consider this case, and sadly
this is not easy to detect via a new rule. For this reason, I have
decided to omit static closure inference from the implementation and
only merge the stateless closure cache. Code with all relevant functions
properly annotated as static will get the full performance benefit.
The RFC was updated accordingly. See
https://wiki.php.net/rfc/closure-optimizations#errata.
If you have any objections to this partial implementation, let me know.
Ilija