PHP 8.6 RFC Seeks to Speed Up Closures — at a Potential Cost

What’s being proposed?

The PHP internals RFC proposes two new optimizations for closures (including arrow functions) aimed squarely at improving performance and memory behavior. The first optimization will attempt to infer that a closure is static when it can be guaranteed not to use $this; the second will cache stateless closures so identical closures don’t spawn new objects on every instantiation. Sounds simple. It isn’t. There are theoretical backward-compatibility breaks on the table, and that’s where the heat is.

Why it matters

Implicitly capturing $this has long produced reference cycles — the closure keeps the object alive and the object keeps the closure alive — which forces PHP’s cycle collector into action. That collector doesn’t always run during a request, meaning unnecessary memory stays allocated. The RFC argues that removing needless captures and reusing identical closures can drastically cut allocations and collector work. It has been reported that on a Symfony Demo test the optimizer inferred 68 out of 87 (~78%) explicitly static closures; synthetic benchmarks claiming a roughly 80% improvement on 10 million instances were shown, and a Laravel template test allegedly avoided 2,384 out of 3,637 closure instantiations, yielding around a 3% speedup on the author’s machine. Real-world gains will vary, of course.

Compatibility and edge cases

This is where the drama lives. Inferring static can change runtime behavior: Closure::bind() and Closure::bindTo() historically throw when trying to bind an object to a static closure. The RFC explicitly allows passing an object to those methods for closures inferred as static — the object is discarded — while keeping the old throwing behavior for closures explicitly declared static. The goal is to soften surprises when inference flips because some unrelated code change nudged a closure into being inferred static. Still, some edges remain. Allegedly, the conditions for inference are “esoteric,” and subtle code changes might produce unexpected shifts in behavior. Backward-compatibility purists will wince.

Vote and what’s next

The RFC is up for a primary vote that requires a two-thirds majority to pass. Voting opened on 2026-02-27 and closes on 2026-03-13. Will the community trade a bit of predictability for measurable speed and memory wins? It’s a classic engineering question — performance versus principle — and the outcome will tell us how conservative a path PHP wants to take going into 8.6.

Sources: php.net, Hacker News