Re: Closure optimizations

On Thu, Jan 22, 2026, at 10:41 AM, Ilija Tovilo wrote: > Hi Larry > > On Thu, Jan 22, 2026 at 5:03 PM Larry Garfield <larry@garfieldtech.com> wrote: >> >> On Wed, Jan 21, 2026, at 1:52 PM, Ilija Tovilo wrote: >> > >> > I've created a PR implementing two new optimizations for closures. [1] >> > There are some theoretical BC breaks, so please let me know if any of >> > them are of concern to you. >> > >> > Of note is that Closure::bind() and Closure::bindTo() usually throw >> > when attempting to bind an object to a static closure. In my PR, this >> > is explicitly allowed only for closures that are inferred as static, >> > but not those that are explicitly static. >> > >> > >> > [1] https://github.com/php/php-src/pull/19941 >> >> This all looks great, Ilija! I am not concerned about the BC mentions, as they seem to be >> accurate anyway. >> >> My one question is about the bindTo() on an inferred static closure. What purpose does >> that serve? I'm assuming that anything that mentions $this in its body won't be marked >> static, and if it doesn't have $this I don't get what value bindTo() would have. >> What's the use case for making an exception here? > > Oops, it seems I've left out some details I was meaning to add. The > aim for allowing the passing of objects to Closure::bind[To]() is to > retain BC when a closure can suddenly be inferred as static due to > seemingly unrelated changes. > > As mentioned, the rules for when static can be inferred are slightly > esoteric. For example, your code may be calling Foo::bar(), which > _looks_ like a static call, but could actually be an instance > grand-parent call (https://3v4l.org/uDi8W#v8.4.14). If you were to > remove this ambiguous call, and the closure could now be inferred as > static, it would be bad if existing Closure::bind[To]() calls would > break because they provide an object. For this reason, > Closure::bind[To]() will _accept but discard_ objects only for > closures inferred as static. > > Ilija Ah, so it's just a "don't break code that's already wrong but not harmfully so" feature. I'm OK with that, but please add that to the RFC. --Larry Garfield