Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128801
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 09 Oct 2025 13:54:32 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <13830641-0fb9-4de9-94ed-8873045ef820@app.fastmail.com>
In-Reply-To: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@app.fastmail.com>
References: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@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 Sat, Jun 28, 2025, at 12:06 AM, Larry Garfield wrote:
> Hi folks.  Arnaud and I would like to present take-2 at Partial 
> Function Application.
>
> https://wiki.php.net/rfc/partial_function_application_v2
>
> It is largely similar to the previous PFA proposal from 2021, though 
> there are a number of changes.  Most notably:
>
> * The implementation is simpler, because FCC already did part of the 
> work.  This RFC can build on it.
> * Constructors are not supported.
> * But optional arguments and named placeholders are supported.
> * It includes pipe-based optimizations.
>
> Note: We realize that this is a non-trivial RFC coming late in the 
> cycle.  We are proposing it now because, well, it's ready now.  If the 
> discussion goes smoothly, we're OK calling a vote on it for 8.5, 
> especially as it would complement pipes so well.  If the discussion 
> runs longer, we're also OK with targeting 8.6 instead.  We'll see how 
> that goes.
>
> <floor opens for discussion, Larry falls through the trap door>

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