Hi everyone
As foreshadowed, I opened the vote for the closure optimizations RFC.
RFC: PHP: rfc:closure-optimizations
PR: Infer static for closures by iluuu1994 · Pull Request #19941 · php/php-src · GitHub
Discussion: php.internals: [RFC][Discussion] Closure optimizations
Original announcement: php.internals: Closure optimizations
The vote will end on 2026-03-13 14:00 UTC.
Ilija
On Fri, 27 Feb 2026 at 13:47, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
Hi everyone
As foreshadowed, I opened the vote for the closure optimizations RFC.
RFC: PHP: rfc:closure-optimizations
PR: Infer static for closures by iluuu1994 · Pull Request #19941 · php/php-src · GitHub
Discussion: php.internals: [RFC][Discussion] Closure optimizations
Original announcement: php.internals: Closure optimizationsThe 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
On Fri, Feb 27, 2026 at 3:16 PM Kamil Tekiela <tekiela246@gmail.com> wrote:
On Fri, 27 Feb 2026 at 13:47, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
>
> As foreshadowed, I opened the vote for the closure optimizations RFC.
>
> RFC: PHP: rfc:closure-optimizationsIs 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
On Fri, Feb 27, 2026 at 2:47 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
RFC: PHP: 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
On 13.03.26 15:58, Ilija Tovilo wrote:
On Fri, Feb 27, 2026 at 2:47 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
RFC: PHP: 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 PHP: rfc:closure-optimizations, 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 PHP: rfc:closure-optimizations.
If you have any objections to this partial implementation, let me know.
Ilija