Hi folks. Arnaud and I would like to present take-2 at Partial Function Application.
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>
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>
--
Larry Garfield
larry@garfieldtech.com
Hi Larry,
I noticed your list of places this applies says "all function/method calls" but then doesn't list object invocation (__invoke magic method). I assume that's just an oversight in the list of places it's applicable rather than an omission in support?
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.
Yea, thank you Arnaud and Larry!
This is a great feature! Hope it will pass smoothly
Good. I think this has a good chance at passing now. This small detail
was one that was arduously discussed on and off list 5 years ago when
I co-proposed it. For a dynamic language, I was a bit surprised by
this. Since it can now be optimized away in one of its most common
cases, that's a big deal, and will make certain people happy. Thanks
for including this optimization.
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>
--
Larry Garfield
larry@garfieldtech.com
Great RFC. It has my vote!
Under the section “func_get_args() and friends,” one of the examples shows:
Some thoughts, I did not yet take an in-depth look:
- Will PFA be available in constant-expressions, following the “First Class Callables in constant expressions” RFC (PHP: rfc:fcc_in_const_expr)?
- It would be good to include an example section not using a regular “free-standing” function in the RFC. The RFC already mentions that all callables are supported, but explicitly showing an example for the possible alternative syntaxes (including `$foo->bar(?)` and `$foo(?)` would be useful.
- Starting with the “RFC Impact” section, several sections of the template are not filled in.
On Sat, Jun 28, 2025, at 4:46 AM, Stephen Reay wrote:
Hi Larry,
I noticed your list of places this applies says "all function/method
calls" but then doesn't list object invocation (__invoke magic
method). I assume that's just an oversight in the list of places it's
applicable rather than an omission in support?
Cheers
Stephen
Yep, that's just an oversight. That should work, although it looks like we don't have a test for it yet. I have left a note for Arnaud to add one and updated the RFC.
On Sun, Jun 29, 2025, at 7:29 PM, Ben Ramsey wrote:
Under the section “func_get_args() and friends,” one of the examples shows:
Some thoughts, I did not yet take an in-depth look:
- Will PFA be available in constant-expressions, following the “First
Class Callables in constant expressions” RFC
(PHP: rfc:fcc_in_const_expr)?
We hadn't discussed it, actually. I'll have to ask Arnaud how difficult that would be. If it's easy enough, I'd say yes it should, but if it proves complicated we may need to punt on it. I'll update the RFC once we know.
- It would be good to include an example section not using a regular
“free-standing” function in the RFC. The RFC already mentions that all
callables are supported, but explicitly showing an example for the
possible alternative syntaxes (including `$foo->bar(?)` and `$foo(?)`
would be useful.
I have added more examples that cover non-function things.
- Starting with the “RFC Impact” section, several sections of the
template are not filled in.
Fixed thanks.