[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.