[RFC] Partial Function Application v2

On Sat, Jun 28, 2025, at 4:46 AM, Stephen Reay wrote:

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:

One too many ?. :-) Fixed thanks. --Larry Garfield

On Mon, Jun 30, 2025, at 2:28 AM, Tim Düsterhus wrote:

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.

I have added more examples that cover non-function things.

Trimmed, as there's nothing to say there AFAIK. --Larry Garfield

Hi Tim, We will update the RFC, but here are a few answers: On Wednesday, July 2nd, 2025 at 17:05, Tim Düsterhus <tim@bastelstu.be> wrote:

PFAs are instances of the Closure class (like FCCs), and will look like a Closure to `var_dump()`, Reflection, and observers. The Closure signature reflects the parameters that are accepted by the PFA, not the underlying function (so it exposes only unbound parameters). function f(int $a, int $b) { } $f = f(?, 2); echo new ReflectionFunction($f); // Output: Partial [ <user> function f ] { @@ test.php 5 - 5 - Parameters [1] { Parameter #0 [ <required> int $a ] } } PFA Reflection is tested in Zend/tests/partial_application/reflection_*.phpt. Parameter names, and which parameters are required, are defined by the RFC. Currently, a few things are broken in the implementation, including parameter default value reflection. Additionally, `var_dump()` exposes bound and unbound args (with the value of bound args). Currently the `var_dump()` output looks like this: object(Closure)#1 (5) { ["name"]=> string(1) "f" ["file"]=> string(%d) "test.php" ["line"]=> int(7) ["parameter"]=> array(1) { ["$a"]=> string(10) "<required>" } ["args"]=> array(2) { ["a"]=> NULL ["b"]=> int(2) } } PFAs do not appear in stack traces, only the function does.

Error messages refer to the underlying function as if it was called directly: Uncaught TypeError: foo(): Argument #2 ($i) must be of type int, array given, in test.php on line 7 The line number refers to the call site of the PFA ($f([])), not its instantiation. However, since PFAs must check argument count before binding them, errors related to argument count refer to the PFA itself. Currently the error message for $f() looks like this: Uncaught Error: not enough arguments for application of foo, 0 given and exactly 1 expected, declared in test.php on line 5 in test.php on line 7

The underlying function name (like FCCs)

See above

Closure::__invoke (like FCCs)

This is broken, but the intent is to support attributes, so that SensitiveParameter and other attributes work as expected. Best Regards, Arnaud

On Fri, Jul 4, 2025, at 5:27 PM, Rob Landers wrote:

Largely because it conflicts with the intent of the closure author, and may have unexpected interaction with optional args otherwise. Eg: function f($a, $b = 0) {} $f = f(?); $f(1, 2); Is 2 bound to $b ? If yes this goes against the intent of the PFA creator. But if not this is weird. Therefore it’s better if that’s not allowed, as that's the least-weird outcome. If the closure author wants to allow trailing arguments, they can use the ... placeholder, which would allow for that. So: function f($a, $b = 0) {} $f = f(?, ...); $f(1, 2); It's self-evident that trailing args are allowed, and that it's the author's intent, so in this case all is well and there's no (unexpected) weirdness. --Larry Garfield

That is only true for userland functions, by the way. Internal functions do care. Historically, we could not do anything about this because variadic functions were only introduced in 5.6, so many functions did not specify that they were variadic and just used func_get_args(). Additionally, some people think it should be unified the other way--internal functions should accept extra args. Anyway, there you go on some history and reasoning of why it is the way it is.

Hi Am 2025-07-22 22:02, schrieb Larry Garfield:

Would it not be appropriate to answer unanswered questions in the discussion (i.e. mine from 12 days ago) and making the previously announced changes (i.e. the ones that Arnaud announced 20 days ago) to the RFC text before claiming that the discussion has quieted down and that the RFC is ready for a vote? Best regards Tim Düsterhus

Hi Am 2025-07-22 22:02, schrieb Larry Garfield:

Besides my remarks about the contents of the RFC, I've also heard some feedback of other core developers being concerned about the complexity of the implementation, particularly at this point in the release cycle. The current PR adds about 6000 lines in total (including tests). Excluding tests it is a net addition of roughly 2000 lines of code deep in the engine: Zend/Optimizer/compact_literals.c | 1 + Zend/Optimizer/optimize_func_calls.c | 6 +- Zend/Optimizer/zend_call_graph.c | 2 + Zend/Optimizer/zend_inference.c | 1 + Zend/zend.c | 3 + Zend/zend_API.h | 3 +- Zend/zend_ast.c | 144 ++++++++++++++++- Zend/zend_ast.h | 17 ++ Zend/zend_builtin_functions.c | 4 + Zend/zend_closures.c | 50 ++++-- Zend/zend_closures.h | 3 + Zend/zend_compile.c | 220 ++++++++++++++++++++++--- Zend/zend_compile.h | 5 +- Zend/zend_execute.c | 87 ++++++---- Zend/zend_execute.h | 19 +++ Zend/zend_fibers.c | 3 + Zend/zend_language_parser.y | 27 ++-- Zend/zend_object_handlers.c | 12 +- Zend/zend_object_handlers.h | 2 +- Zend/zend_partial.c | 1237 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Zend/zend_partial.h | 67 ++++++++ Zend/zend_types.h | 4 + Zend/zend_vm_def.h | 218 ++++++++++++++++++++++++- Zend/zend_vm_execute.h | Bin 2280557 -> 2293393 bytes Zend/zend_vm_handlers.h | Bin 93176 -> 93469 bytes Zend/zend_vm_opcodes.c | Bin 9505 -> 9667 bytes Zend/zend_vm_opcodes.h | Bin 13859 -> 14051 bytes configure.ac | 1 + ext/opcache/jit/zend_jit.c | 3 + ext/opcache/jit/zend_jit_helpers.c | 12 ++ ext/opcache/jit/zend_jit_ir.c | 15 ++ ext/opcache/jit/zend_jit_vm_helpers.c | 16 +- ext/opcache/zend_file_cache.c | 4 +- ext/opcache/zend_persist.c | 1 + ext/opcache/zend_persist_calc.c | 2 + ext/reflection/php_reflection.c | 58 ++++++- ext/reflection/php_reflection.stub.php | 2 + ext/reflection/php_reflection_arginfo.h | Bin 111516 -> 111497 bytes ext/zend_test/fiber.c | 3 + win32/build/config.w32 | 2 +- 40 files changed, 2152 insertions(+), 102 deletions(-) For comparison: Clone-with was 700 lines, turning clone into a function was 200 lines, #[\NoDiscard] was 1050 lines, the (void) cast was 150 lines (all *including* tests). All these RFCs together (including tests!) are smaller than the implementation of PFA. The current proof of concept PR for PFA at https://github.com/arnaud-lb/php-src/pull/12 has 5 open ToDo items in the initial PR description and CI is red. I've tested the current version of the PR against Tideways and noticed that calls to PFA Closures are completely invisible to observers and the `zend_test` observers confirm this. For: <?php function foo(int $a, int $b, int $c, int $d): int { return array_sum([$a, $b, $c, $d]); } function main() { $f = foo(1, ?, ?, 4); $f = $f(2, ?); var_dump($f(3)); } main(); running `sapi/cli/php -d zend_test.observer.enabled=1 -d zend_test.observer.observe_all=1 test.php` outputs: <!-- init 'test.php' --> <file 'test.php'> <!-- init main() --> <main> <!-- init array_sum() --> <array_sum> </array_sum> <!-- init var_dump() --> <var_dump> int(10) </var_dump> </main> </file 'test.php'> Erroneously indicating that `array_sum()` is directly called by `main()`. The call to `foo()` is nowhere to be seen. As of now the implementation very clearly is incomplete. Given the complexity of the implementation, there is a significant risk that it cannot be stabilized until hard freeze and that “amendments” to the RFC will need to be made due to unexpected issues popping up during the finalization of the implementation and review. Best regards Tim Düsterhus

On Tue, Jul 22, 2025, at 3:02 PM, Larry Garfield wrote:

Hi folks. Arnaud and I have decided to hold off on the PFA vote for a while to give time to address late-arriving questions and finish off the implementation. That means it's now pushed to 8.6, and I've updated the RFC accordingly. We're not pausing though, so expect another update soon-ish. Meanwhile, if anyone else wants to weigh in on the trailing args question or repositioning parameters question, now is the time. --Larry Garfield

On Wed, Jul 23, 2025, at 3:56 AM, Tim Düsterhus wrote:

I have added the following example: function foo(int $a = 5, int $b = 1, string ...$c) { } $pfa = foo(?, ?, ?, ?); // Equivalent to this: // Note that $a and $b become required, because there must be at least 4 arguments. $pfa = fn(int $a, int $b, string $c1, string $c2) => foo($a, $b, $c1, $c2);

I have added the following equivalent: $c = fn(string $s, Point $p, int $m = 0) => stuff(1, $s, 3.14, $m);

LOL. That was completely unintentional. :-) However, I have gone through and added numbers to the variable names to clarify their original ordering.

Hm. I think you're right, with the Extraneous Args section's clarification, the others should likely have a trailing ...$args as well. I will clarify with Arnaud when he returns and update accordingly.

The order is determined by the original function. The same is true for a normal function call. function foo(int $a, int $b, int $c) {} // All of these are equivalent. foo(a: 1, b: 2, c: 3); foo(b: 2, a: 1, c: 3); foo(c: 3, b: 2, a: 1); foo(1, 2, 3); So the same is true of a PFA: foo(a: ?, b: 2, c: ?); foo(b: 2, a: ?, c: ?); foo(c: ?, b: 2, a: ?); foo(?, 2, ?); All of those produce the same result.

I can't find an answer to that in my notes, so I'll have to defer to Arnuad when he returns. (Ilija tells me he's back Monday.) I think so, but I'm not certain. --Larry Garfield

Hi Am 2025-10-09 20:54, schrieb Larry Garfield:

I still believe that this is *less* confusing, as I outlined before.

I've given it another read. Remarks:

What will happen if the original function already has a parameter named $args0?

Typo: 1i.

The example desugaring is inconsistent with the previously explained semantics: Here an arbitrary number of arguments is accepted, but previously it says "will result in a Closure with no parameters".

I believe this example is outdated, since the ... must come last now. (the 's' and 'i' parameters are also missing the "number").

This example desugaring seems to be incorrect with regard to the naming of the variadic parameters.

Just to spell this out explicitly: I believe this should print "1, 3, 2, 4".

`$` missing before `y`.

The error message for this one appears to be a copy and paste error.

Is it actually "place holder" with a space?

Minor formatting nit: Missing space after colon.

Typo: Missing dot in splat. ------ Questions: - Are PFAs legal in constant expressions? e.g. does the following work: `const Foo = intval(?, 10);`? - The RFC says that it compiles down to the equivalent Closure. Can you add an example of a stack trace for completeness? Ideally one with SensitiveParameter working. That will then showcase the closure naming, SensitiveParameters and that there are two stack frames for the call. Best regards Tim Düsterhus

Hi I also find it confusing if I define a different parameter order in the partial function and then this order is automatically overridden to the original order rather than being used. When I consciously change the parameter order, I expect this order to be preserved in the resulting function. That's the behavior I would expect as a developer. Cheers Joshua Rüsweg

On Thu, Oct 9, 2025, at 1:54 PM, Larry Garfield wrote:

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

Hey Larry, On 16.11.2025 21:51:59, Larry Garfield wrote:

I've just gave the RFC another deep read, and found only mentions of pass-by-ref. But not return-by-ref, and neither does the implementation handle this case: # ./sapi/cli/php -r 'function &r(&$a) { return $a; } $a = 1; $b = &r($a); ++$b; var_dump($a);' int(2) # ./sapi/cli/php -r 'function &r(&$a) { return $a; } $a = 1; $b = &r(?)($a); ++$b; var_dump($a);' Notice: Only variables should be assigned by reference in Command line code on line 1 int(1) Was this an oversight or intentionally omitted in the RFC? If it was, I'd like to hear the reasoning on this. Thank you, Bob