Closure::getCurrent() for recursion

Hi

I looked at it earlier, when you opened the PR.
I also remember the discussion from the past.
Your PR is super logical, and a super easy implementation.
Language change seems unnecessary indeed.
LGTM, ship it!

Kind regards
Niels

Hi everyone

A few years ago, an RFC was proposed to introduce special syntax for
self-referencing closures, mainly used for implementing recursion.

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

The proposed solution allows specifying a variable that will be
assigned the closure object on function entry.

$fibonacci = function (int $n) as $fn {
if ($n === 0) return 0;
if ($n === 1) return 1;
return $fn($n-1) + $fn($n-2);
};

This is essentially already possible through a by-reference capture.

$fibonacci = function (int $n) use (&$fibonacci) { ... };

This cannot be a by-value capture because by the time the closure is
created and variables are bound, $fibonacci is not assigned yet. The
downside of by-reference capturing is that if $fibonacci is
accidentally reassigned, the reference within the closure is also
changed.

However, I consider a language change largely unnecessary. Instead,
this may be solved with a very simple static function:
Closure::getCurrent().

$fibonacci = function (int $n) {
if ($n === 0) return 0;
if ($n === 1) return 1;

 $self = Closure::getCurrent();
 return $self($n-1) + $self($n-2);

 // Or
 return Closure::getCurrent()($n-1) + Closure::getCurrent()($n-2);

};

Another suggestion was to introduce a magic constant CLOSURE.
However, this would be misleading, given it can refer to different
closure instances, thus not actually being constant.

You can find the implementation here:
https://github.com/php/php-src/pull/18167

I picked the name Closure::getCurrent() to be consistent with
Fiber::getCurrent(). Contrary to fibers, calling Closure::getCurrent()
from non-closures is nonsensical and thus disallowed, resulting in an
Error exception. It will only succeed when called directly from
closures. It will not recurse the call stack.

Do you have thoughts or concerns with this solution? If not, I'm
planning to merge it into master in a few weeks.

Ilija

PHP now officially better than JavaScript, which had arguments.callee
since inception, but was then deprecated without replacement.

Hello Ilija,
Nice addition! I thought about edge cases and what the desired output is
with nested closures?

Example:
<?
$a = function (int $numberA) {
$b = function (int $numberB) {
if($numberB < 10) {
return Closure::current(10);
}
return $numberB;
};
return $b($numberA) + $numberA;
};

var_dump($a(4));

Hi everyone

This is essentially already possible through a by-reference capture.

$fibonacci = function (int $n) use (&$fibonacci) { ... };

This cannot be a by-value capture because by the time the closure is
created and variables are bound, $fibonacci is not assigned yet. The
downside of by-reference capturing is that if $fibonacci is
accidentally reassigned, the reference within the closure is also
changed.

However, I consider a language change largely unnecessary. Instead,
this may be solved with a very simple static function:
Closure::getCurrent().

How about mutual recursion, where two of these functions call each
other? Currently one can write

$left = function(array $a) use(&$second) { ... };
$second = function(array $a) use($first) { ... };

(The second can capture the first by value, but the first still needs to
capture the second by reference.)

With Closure::getCurrent(), how does either function reference the other?

Hi

Am 2025-03-31 22:38, schrieb Ilija Tovilo:

Do you have thoughts or concerns with this solution? If not, I'm
planning to merge it into master in a few weeks.

I don't particularly like this kind of “magic scope / backtrace
introspecting” functions, but it certainly is a pragmatic solution (and
there's sufficient precedent, including Fiber::getCurrent()).

Best regards
Tim Düsterhus