Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130191
Precedence: list
MIME-Version: 1.0
References: <CAPyj-LAdQmUM7UEpEA+g6ezOq0zpOq=V8puZ=eeGX4HH0MBrMw@mail.gmail.com>
 <CAGBsUrcJrCn7bSgkAfLkMJ-6SWptsspvjZR6snd4Gr=A1ne+NQ@mail.gmail.com>
In-Reply-To: <CAGBsUrcJrCn7bSgkAfLkMJ-6SWptsspvjZR6snd4Gr=A1ne+NQ@mail.gmail.com>
Date: Fri, 27 Feb 2026 15:23:02 +0100
Message-ID: <CAPyj-LBtvahu2u9XGtKRLDHwdw=KELJXOp1mi+Xakm84XoYk7w@mail.gmail.com>
Subject: Re: [PHP-DEV] [Vote] Closure optimizations
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Kamil

On Fri, Feb 27, 2026 at 3:16=E2=80=AFPM 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: https://wiki.php.net/rfc/closure-optimizations
>
> 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 bene=
fit codebases that prefer not to add static to avoid visual clutter, as wel=
l as those who aren't aware of these subtle performance implications.

Ilija