[RFC] Closure self-reference

[KapitanOczywisty]

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

Todo:

• Plug leak
• Fix segfault when calling $fn->call($class, 3);
• Fix opcache
• Arrow functions
• Check if ZEND_BIND_SELF_REFERENCE is needed somewhere in opcache
  • May be needed in Zend/Optimizer/sccp.c and/or Zend/Optimizer/zend_dfg.c - not sure
• More testing

Notes:

• _zend_ast_decl->childs had to be extended to fit this feature
  maybe should be merged with static binding AST?
• as $fn is placed before use(...)
  might be sensible to push as after use or even after return type (though latter would look confusing)
  function(int $a) as $fn use($b) : int {} vs
  function(int $a) use($b) as $fn : int {} vs
  function(int $a) use($b) : int as $fn {}

[Danack]

@mvorisek the internals list is where alternatives to RFCs are discussed. Pull-requests are only for technical discussion of the PR.

[dstogov]

Just a quick idea...
May be it's better to use some predefined name e.g. __CLOSURE__.
From the implementation point of view, it should reference EX(func).
This way it should be possible to capture it's value into a variable (by value) or call directly with minimal overhead.

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

I don't tell this proposal is bad and I didn't think about all consequences of my idea.

[KapitanOczywisty]

@dstogov I was thinking about Closure::current, now I know that both of these would require change in Closure::call - fake closure would have to be removed or closure recreated on __CLOSURE__ (then __CLOSURE__ !== __CLOSURE__ ?) or parser would search for __CLOSURE__ in function body (like arrow fn auto-capture). This would be also first magic constant not returning scalar type.

as $fn could also be moved to use() e.g. use(fn as $fn, $a, $b). We'll see what discussion on internals brings.

[medabkari]

Any news regarding this RFC?