[RFC] Partial Function Application v2

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.

Under the section “func_get_args() and friends,” one of the examples shows:

$f = foo(?, ?, ??);

I assume this is a typo?

One too many ?. :-) Fixed thanks.

--Larry Garfield

Hi

Am 2025-06-28 07:06, schrieb Larry Garfield:

https://wiki.php.net/rfc/partial_function_application_v2

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
  (https://wiki.php.net/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.

Trimmed, as there's nothing to say there AFAIK.

--Larry Garfield

Hi Tim,

We will update the RFC, but here are a few answers:

I've now had a quick look at the implementation and the following
questions came up that the RFC does not answer (and the tests in the PR
do not obviously answer either):

How will PFA calls appear in a stack trace and how will PFA Closures
look like to var_dump(), Reflection, and to observers?

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.

Classic FCC are 100% identical to the underlying function and thus can
just “pretend” they are the underlying function, but that doesn't work
for PFA. Consider the following:

function foo(string $s, int $i) {
var_dump($s, $i);
}

$f = foo("abc", ?);

$f([]);

How will the error message for the resulting TypeError look like?

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

var_dump((new ReflectionFunction($f))->getName());

The underlying function name (like FCCs)

var_dump((new ReflectionFunction($f))->getParameters());

See above

is_callable($f, callable_name: $name);
var_dump($name);

Closure::__invoke (like FCCs)

function foo(string $s, #[\SensitiveParameter] int $i) {
throw new \Exception();
}

$f = foo("abc", ?);

$f(123);

How will the stack trace look like? Does #[\\SensitiveParameter] work
properly?

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

Best Regards,
Arnaud

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>

--
Larry Garfield
larry@garfieldtech.com

Hi Larry,

I hope your trip through the trap door is largely uneventful with a
smooth integration into 8.5.

My only question: why does this implementation care if you specify too
many arguments when PHP doesn’t care if you call a function with too
many arguments?

I think it’s a good thing that it cares, and I think PHP itself should
care, but should this RFC change that expectation?

— Rob

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

My only question: why does this implementation care if you specify too many arguments when PHP doesn’t care if you call a function with too many arguments?

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:

It seems the discussion has quieted down and wasn't particularly
contentious to begin with (whew), so we're just about ready for a vote.

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:

It seems the discussion has quieted down and wasn't particularly
contentious to begin with (whew), so we're just about ready for a vote.
However, Arnaud went on vacation and didn't remember to tell me when
he'd be back. :-) So I'm going to wait a few more days just in case he
has any last minute comments, but start the vote either when he returns
or Monday the 28th, whichever comes first. (That gets the vote
complete before the deadline for 8.5.)

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

Hi folks. Just a quick update: We've made one small change to the RFC.
Specifically, in order to prevent accidentally calling optional
arguments from callback locations like array_map() or array_find(), a
partial created with foo(?) will ignore any additional arguments passed
to it, and will not pass those through to the underlying function. A
partial that uses foo(?, ...) will pass through whatever it gets.

This is mainly to avoid passing an array key from those functions to a
callback function that has an optional second parameter, which is not
intended to get a key string. In practice this is what most people
would expect would happen, but we're calling it out explicitly. (I'm
not even sure it's a behavior change from what we had before, in
practice.)

cf:
https://wiki.php.net/rfc/partial_function_application_v2#extraneous_arguments

It seems the discussion has quieted down and wasn't particularly
contentious to begin with (whew), so we're just about ready for a vote.
However, Arnaud went on vacation and didn't remember to tell me when
he'd be back. :-) So I'm going to wait a few more days just in case he
has any last minute comments, but start the vote either when he returns
or Monday the 28th, whichever comes first. (That gets the vote
complete before the deadline for 8.5.)

--Larry Garfield

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

Hi

Am 2025-06-28 07:06, schrieb Larry Garfield:

https://wiki.php.net/rfc/partial_function_application_v2

I've now given the RFC an in-depth read. I have the following remarks:

If the function is variadic, there are two additional rules:

• Any positional placeholders that run into the variadic portion become
  required.
• If any positional placeholders run into the variadic portion, all
  prior remaining placeholders become required. However, those parameters
  may not be called with named arguments, as there is no name to use.

I do not understand what “running into the variadic portion” means. An
example would probably be helpful. The first bullet point is probably
intended to mean the following:

 function foo($a, ...$b) { }
 $pfa = foo(?, ?, ?, ?);

Now $pfa has 4 required parameters, despite foo() only having 1?

But I don't understand what the second bullet point is intended to say.

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);

In the placeholder semantics section:

While in theory that means a call like this would be legal:

From what I see this specific case is not part of the examples section
either. Including the desugaring of this extreme case would certainly
help understanding.

I have added the following equivalent:

$c = fn(string $s, Point $p, int $m = 0) => stuff(1, $s, 3.14, $m);

In the “Examples” section:

The choice of parameters names makes it hard to understand the examples,
particularly when named parameters are used to provide arguments out of
order. Including the “position” in the name of the parameter would make
it easier to follow the example, since it is not necessary to look up
the signature of stuff() all the time. (it becomes manageable if you
read it as a sentence "is FPM")

LOL. That was completely unintentional. :-)

However, I have gone through and added numbers to the variable names to clarify their original ordering.

In the “Examples” section:

Is the “thunk” example accurate? It's the only example where the
resulting “PFA” includes a variadic picking up the remaining arguments.

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.

In the “Examples” section:

$c = stuff(?, p: $point, f: ?, s: ?, m: 4);

It is unexpected to me that this definition will take $s before $f
in the resulting Closure. The explanation says that the “order does not
matter”, but it is certainly unexpected that the order changes during
desugaring.

In fact, the "(four(c: ?, d: 4, b: ?, a: 1))(2, 3);" example further
down below seems to contradict this.

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.

In the “Extraneous arguments” section:

I disagree with silently ignoring trailing arguments, because it adds
to the existing inconsistency between userland and internal functions.
In fact there was a recent-ish discussion (I would provide a link, but
can't find it right now) about allowing userland functions to define
that they want to be called with a strict arity.

While it would add to the symbol soup, having an explicit “ignore the
argument at this position” indicator would be useful. For example:
$firstNonZero = array_find($arr, intval(?, _)); (I understand this
specific one doesn't work, because _ is a valid constant).

It is not clear to me from the RFC, why the ... placeholder to
indicate “all remaining arguments” must come between positional and
named parameters. It would make more sense to me for it to become last,
because it would also make it clearer that named parameters take
priority over .... Is there some technical limitation that caused this
choice to be made?

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