Hi everyone
A week ago, I sent an e-mail to internals regarding two closure
optimizations with some subtle BC breaks. [1] While nobody objected, I
decided to create a short RFC anyway to avoid any possible controversy
due to the BC breaks. You can find it here:
https://wiki.php.net/rfc/closure-optimizations
Regards,
Ilija
Le 31 janv. 2026 à 00:43, Ilija Tovilo tovilo.ilija@gmail.com a écrit :
Hi everyone
A week ago, I sent an e-mail to internals regarding two closure
optimizations with some subtle BC breaks. [1] While nobody objected, I
decided to create a short RFC anyway to avoid any possible controversy
due to the BC breaks. You can find it here:https://wiki.php.net/rfc/closure-optimizations
Regards,
Ilija
Hi,
The examples of the RFC all use the function () { } construct. I guess it does also apply to closures constructed with fn() => ?
—Claude
Hi Claude
Le 31 janv. 2026 à 00:43, Ilija Tovilo tovilo.ilija@gmail.com a écrit :
The examples of the RFC all use the
function () { }construct. I guess it does also apply to closures constructed withfn() =>?
Yes, the same applies to arrow functions. I clarified in the text and
added a short example.
Ilija
Hey Ilija,
Hi everyone
A week ago, I sent an e-mail to internals regarding two closure
optimizations with some subtle BC breaks. [1] While nobody objected, I
decided to create a short RFC anyway to avoid any possible controversy
due to the BC breaks. You can find it here:https://wiki.php.net/rfc/closure-optimizations
Regards,
Ilija
I'm a bit disappointed that you felt necessary to introduce bureaucracy
for a straightforward very minor BC break. I don't like this something
to become necessary or expected in future. Sending that email was
completely sufficient.
I would like to encourage you to recognize that and simply merge your
pull request.
Thanks,
Bob
Hi Bob
https://wiki.php.net/rfc/closure-optimizations
I'm a bit disappointed that you felt necessary to introduce bureaucracy for a straightforward very minor BC break. I don't like this something to become necessary or expected in future. Sending that email was completely sufficient.
I would like to encourage you to recognize that and simply merge your pull request.
I agree that the BC break is fairly minimal. What made me decide to
create an RFC after all is highlighted here:
ReflectionFunction::getClosureThis() will now return
NULLfor closures that are inferred as static. This might be slightly surprising, given static inference does not work 100% reliably, limited by the rules previously described.
ReflectionFunction::getClosureThis() will work as long as the closure
uses $this, but it will also work if it calls static methods. Once you
remove the static call, it will break. Now, I don't think
ReflectionFunction::getClosureThis() is something many people rely on,
nor should they, but it is nonetheless surprising. I'd like to avoid
the situation where this is categorized as a bug that is effectively
impossible to solve without removing the optimization.
Ilija
Hi Ilija,
Thank you for this improvement. If I understand correctly, one of the
predicted BC changes will fix one of the issues with unit test comparisons.
The sebastianbergmann/comparator library cannot compare closures, because
each closure is in fact a different instance. With your change, this might
be resolved for static closures. So I see this is in fact very beneficial
for the unit testing.
https://github.com/sebastianbergmann/comparator/issues/129
Kind regards,
Jorg
On Sat, Jan 31, 2026 at 12:41 AM Ilija Tovilo tovilo.ilija@gmail.com
wrote:
Hi everyone
A week ago, I sent an e-mail to internals regarding two closure
optimizations with some subtle BC breaks. [1] While nobody objected, I
decided to create a short RFC anyway to avoid any possible controversy
due to the BC breaks. You can find it here:https://wiki.php.net/rfc/closure-optimizations
Regards,
Ilija
Hi everyone
Given there hasn't been any recent feedback or change to the RFC, I
intend to start the vote on Friday.
Ilija