[RFC] Partial Function Application for instance of non-static methods ("$this")

Hi

Am 2026-01-22 16:33, schrieb Derick Rethans:

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

We propose allowing a named parameter $this: ? to be combined with the
“scope resolution operator” syntax of referring to a method.

I can't say I am entirely sold on the syntax here — starting with a $
makes it look like a variable.

Yes, it certainly requires some getting used to it. It's the best we
could come up with, but if there are any better suggestions, we're open
to hearing those. I'd like to note the “Rejected Features” section,
since it lists some non-workable alternatives we considered.

Since the $this: ? parameter does not refer to a parameter in
the underlying argument list and thus there is no ambiguity with
regard to positional parameters it may be placed at any position
of the parameter list

I think I would be keen on requiring this to be the first in the
argument list.

Although there is no ambiguity, I also can't see why you would want to
have it anywhere else.

Being able to “reorder” parameters to (better) fit a specific callback
signature is an explicit feature of PFA that we also wanted to support
for $this.

As an example, suppose objects could be used as an array key.
array_find() first passes the value and then the key to the callback.
In this case users might want to do the following:

 class SomeObject {
     public function __construct(private string $value) { }
     public function hasMatchingValue(string $value) { return $value 

=== $this->value; }
}

 $array = [
     new SomeObject('foo') => 'bar',
     new SomeObject('baz') => 'baz',
 ];

 array_find(SomeObject::hasMatchingValue(value: ?, $this: ?), 

$array);

In this case array_find() is supposed to return 'baz', since this is
where the values match.

It may also not be used when partially applying an instance
method with a known object.

$c = $dateTime->format($this: ?, "c"); // Fatal error: Invalid use of
$this placeholder

Can you explain (in the RFC) what you mean by "known object" — I don't
think the language on what this means is clear enough.

I have rephrased that to “It may also not be used when partially
applying an instance method using the -> operator, since the object is
already specified:”

Best regards
Tim Düsterhus

Hi

Am 2026-01-22 18:30, schrieb Mathieu Rochette:

I often whished something like this existed :) Didn't get trough to
suggest it because I wasn't sure of the syntax either (and lazyness)

Thank you for participating in the discussion of this RFC then. Having
more voices available helps building things that suit the community best
:-)

still, my syntax suggestions:

array_map(DateTimeImmutable->format("c"), $dates);

Unfortunately this doesn't work, because it is a already-legal method
call on a method stored in the constant called DateTimeImmutable. See:
https://3v4l.org/3khkT#veol

I noticed ?->method(?) was considered; evne if it was possible, I
would prefer if the type was explict, as you may want to use an
interface name (or a union type, etc.) too

Union types would likely be unsupported either way, since multiple
members of the union could have incompatible signatures for the same
method. Interfaces are fully supported with the currently proposed
syntax (it's explicitly mentioned in the RFC).

Best regards
Tim Düsterhus

Hi

Am 2026-01-23 00:25, schrieb Theodore Brown:

Thank you for your work on this. However, I'm struggling to see the
benefit
of this syntax over short closures given the examples in the RFC:

$dates = [
    new DateTimeImmutable('now'),
];

$formattedDates = array_map(DateTimeImmutable::format($this: ?, 

"c"), $dates);

To provide some background on how this RFC came about: Arnaud and I were
discussing my recent array_map() optimization
(https://github.com/php/php-src/pull/20934) that compiles array_map()
calls that either use FCC or PFA as the callback into the equivalent
foreach() loop. The optimization skipped when an actual Closure is
passed, since full-blown Closures come with all kinds of scope-related
(edge) cases to consider, making it much more complicated. I noted that
I believed that with PFA many array_map() cases could be handled
without a full Closure and that it was unfortunate that it didn't work
for “filling in the object itself”.

I then came up with the basic idea for the proposed syntax half-a-minute
later and we figured it would at least be worth proposing it, since it
mapped onto the existing PFA semantics in a fairly straight-forward
fashion.

This saves only three characters compared to a short closure:

$formattedDates = array_map(fn(DateTimeImmutable $d) => 

$d->format("c"), $dates);

The return type would be missing in that snippet. And depending on your
codebase's policy you might also need static in front of the short
Closure. This might become less relevant with
https://news-web.php.net/php.internals/129825, but personally I would
still consider it a best-practice to be explicit.

Personally I also feel that short Closures have some “visual overhead”
in that they don't feel like a simple “method reference”. It's quite
similar to how PFA itself is technically redundant with short Closures,
but allows to be more explicit with the intention (which enabled the
optimization mentioned above).

Furthermore, duplicating the array's type isn't necessary when IDEs and
static
analysis can infer it, so short closures can usually be even more
concise:

$formattedDates = array_map(fn($d) => $d->format("c"), $dates);

This is true when the Closure is immediately consumed, but not when it's
intended to be reused at a later point, e.g. with the Symfony Form
example where the IDE / Static Analyzer needs some deeper knowledge
about how the 2nd and 3rd parameter of ->add() interact.

I also find the use of $this as a named argument confusing. It makes
it
appear as though the current class instance is somehow being passed to
the
method, when this isn't the case.

That's fair. I would've hoped to just use this: without the $, but
that comes with the breaking change for variadics mentioned at the
bottom of the RFC.

A short closure is barely any longer, and makes it easier to add
additional
logic when needed:

'choice_label' => fn(Category $c) => $c->getName(),

'choice_label' => fn(Category $c) => strtoupper($c->getName()),

Note: Return type + Static also missing here. And of course if more
parameters would be passed, it would scale differently (since more types
are required for proper autocompletion).

Best regards
Tim Düsterhus

Hey Tim, I think you jumped to a conclusion without exploring the space
of possibilities fully:

With regard to your comment on the PR and the “Open Issue” listed in
the RFC about the name for the $this parameter in the resulting
Closure we have two options to offer:

1. ClassName::methodName(this: ?) with the parameter being called
   $__this.

2. ClassName::methodName($this: ?) with the parameter being called
   $this.

Notably ClassName::methodName(this: ?) with the parameter being
called $this is not an option, because it would result in
inconsistent behavior:

ClassName::methodName(this: ?) semantically relies on $this never
being a valid parameter name, such that this: ? can unambiguously
refer to the “implicit $this value” for a method call. However when
the parameter in the generated Closure would be called $this, there
is some ambiguity for cases like:

     $c = DateTime::format(this: ?, format: ?);
     $c2 = $c(this: ?, format: 'c');

Is this: ? in the definition of $c2 referring to the $this
parameter of the generated Closure or is it an attempt to partially
apply the Closure object for the Closure::__invoke() method that
is referenced by $c?

Similarly allowing this: $object with a concrete value is explicitly
disallowed, because of possible ambiguity with regard to inheritance:

     class P { public function m() { echo "P"; } }
     class C extends P { public function m() { echo "C"; } }

     // is this calling P::m() or is this calling C::m()?
     P::m(this: new C());

This would however prevent calling a partially applied instance method
with named arguments:

     $c = DateTime::format(this: ?, format: ?);
     // Disallowed, because this: must be partially applied.
     $c(this: new DateTime(), format: 'c');

If the syntax to define the PFA was using C::m($this: ?), $this in
the resulting Closure would just work like any other parameter.

1. ClassName::methodName(this: ?) with the parameter being called
   $__this.

2. ClassName::methodName($this: ?) with the parameter being called
   $this.

Allowing P::m(this: $object) with a concrete value should behave
identically to P::m(this: ?)($object), which in turn should behave
identically to $object->m() if called outside of C (or its children),
otherwise equivalently to private function forwardM() { return P::m(); } $object->forwardM(); (i.e. a (grand)parent class method can always be
called).

This approach is consistent with how method calling works in child classes.

More normatively for any class P and method m, P::m(this: ?) needs to
store the class where the PFA closure is created as called_scope on the
Closure when that class is instanceof P unless P::m is abstract, so that
any call to the resulting closure is checked against that called_scope:
If the $this object the Closure is ultimately called with is instanceof
the called_scope of the Closure, the specific given method must be
called (i.e. specifically P::m()), otherwise the object is merely
checked for being instanceof P and the method m on the $this object is
called directly.

Defining it this way preserves LSP guarantees, with maximum flexibility

• making it for example perfectly possible to call
  array_map(ParentClass::someValue(this: ?), $objectsArray) without being
  surprised that it subtly actually calls the child method someValue on
  objects which are instanceof the containing class.

The neat benefit is that any $obj->method() call is now generalized (on
the surface of the language semantics, obviously not implementation
wise) as {get_class($obj)}::method(this: $obj), which makes the this-PFA
a trivial extension of just having ? for the this parameter.
It also obsoletes any concerns about how the this parameter ends up
called in the resulting PFA - because it's just a "normal" parameter
then, from the perspective of the caller.

The only small caveat is Closure::__invoke(this: ?), which literally is
just sort of an identity function and thus useless. To solve that, we
should just decide to have an explicit this parameter on Closures take
precendence. (Ultimately __invoke is more of an implementation detail of
Closure, than anything else).

Also of note is that having a proper implicit $this parameter on methods
must not have a position (as in positional parameters). Otherwise
conflicts arise with e.g. the implicit $this forwarding in parent::m()
syntax in class scope. (obviously, once you create a PFA P::m(this: ?,
?) the first positional parameter becomes the $this parameter and the
original first parameter is now the second one.)

To summarize: Please introduce a first-class implicit $this parameter on
any non-static method call, and have PFA work naturally with it, without
doing contortions in language semantics / introducing a very
PFA-specific syntax.

Thanks,
Bob

P.s.: You should possibly add to future scope allowing
object::someMethod(this: ?) or class::someMethod(this: ?) to allow
proper duck typing without having to know the actual object behind.
That's something I see people asking for, too.