Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129008
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 30 Oct 2025 13:44:31 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <a2439dc9-dbb3-4f5f-84f2-b33f988925ea@app.fastmail.com>
In-Reply-To: <13830641-0fb9-4de9-94ed-8873045ef820@app.fastmail.com>
References: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@app.fastmail.com>
 <13830641-0fb9-4de9-94ed-8873045ef820@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Partial Function Application v2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Oct 9, 2025, at 1:54 PM, Larry Garfield wrote:

> Hi folks.  PFA is back. :-)
>
> Since our last episode, Arnaud has greatly revised the implementation.  
> Rather than emulating a closure and all the associated behavior, the 
> new approach compiles PFAs into normal closures at runtime, leveraging 
> opcache.  The resulting closure is then "just a closure," and will 
> behave like any other.  That means, for instance, its behavior in 
> debugging, reflection, etc. is all self-evident.
>
> There were a few small behavior changes as a result, but not 
> dramatically.  Mainly it impacted variadic cases, where parameter names 
> are now auto-generated when appropriate rather than simply being 
> unnamed.
>
> We have also changed the order of placeholders from "positional, 
> variadic, named" to "positional, named, variadic."  Meaning the `...` 
> "and the rest" placeholder is always at the end of the call.
>
> One outstanding question is whether to allow reordering of parameters 
> in the PFA closure by using named arguments.  With this implementation, 
> Arnaud says it's possible to do if we decide to.  I am still concerned 
> that it would create too much complexity and confusion in practice.  
> But we're willing to go with a broad consensus if it emerges.
>
> https://wiki.php.net/rfc/partial_function_application_v2
>
> --Larry Garfield

Another set of updates.

* Some improvements to the error handling and error messages.
* Clarified that PFA is compatible with constant expressions.
* Clarified when the resulting closure is static or not.

The main change is we revisited how extra arguments are handled.  Long story short, they now forward only if the PFA has a ..., and how they forward depends on if the underlying function is variadic or not.

The RFC now includes more precise examples of how the desugaring works, including the variadic/func_get_args cases, which should make it all a lot clearer.

The one outstanding question is whether we allow reordering using named arguments or preserve the underlying order.  Arnaud says either one is doable.  So far, only 2 people have commented on it (favoring reordering).  We still want feedback from more people to see if there really is a consensus one way or another.  (2 people is too small a sample size to draw any conclusions.)

Also, if anyone not named Tim would like to weigh in, now is the time. :-)

--Larry Garfield