Re: [RFC] Partial Function Application v2

Hi Am 2025-07-02 18:23, schrieb Arnaud Le Blanc:

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

I don't think this has happened yet.

On Wednesday, July 2nd, 2025 at 17:05, Tim Düsterhus <tim@bastelstu.be> wrote:

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.

Yes, that was clear.

The Closure signature reflects the parameters that are accepted by the PFA, not the underlying function (so it exposes only unbound parameters).

That makes sense.

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

Thank you. I'm not sure if I like this, particularly the name. Compared to FCCs saying that a PFA of f has the name f is misleading, since the parameter list is different and thus functions are not interchangeable. Instead the name could perhaps be {partial:f()}, similarly to the new closure names?

PFAs do not appear in stack traces, only the function does.

This would be consistent with __call(), but similarly to the above, it could be misleading, since the parameters shown in the stack trace do not match what the user has written at the call site. Would it be possible to insert a fake frame for the call to the partial or is this prohibitively expensive?

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.

See above regarding the stack trace.

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

Yes, that makes sense. It's probably not necessary to indicate where the original function was declared, we don't do this for other errors related to the signature either.

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

The underlying function name (like FCCs)

See above for my var_dump() comments.

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

Closure::__invoke (like FCCs)

I changed that with PHP 8.5. With PHP 8.5 is_callable() is consistent with ReflectionFunction::getName() for FCCs. See: https://github.com/php/php-src/pull/18063 Best regards Tim Düsterhus