RFC: Support Closures in constant expressions

[TimWolla]

Most notably this allows to use Closures as Attribute parameters.

RFC: https://wiki.php.net/rfc/closures_in_const_expr

[bwoebi]

May I suggest automatically making Closures in constants static? (just the same like if you were to declare some closure without static on top-level code)
Non-static Closures of attributes probably could trivially get a $this reference to the instance of the attribute they are on.

I realize though that for properties we should require static for now. (unless you are going to provide properties with $this on new SomeClass...)

[TimWolla]

May I suggest automatically making Closures in constants static? (just the same like if you were to declare some closure without static on top-level code)

@bwoebi It does not look like top-level closures are implicitly static:

https://3v4l.org/dJiqK

<?php

class Foo { }

$foo = function () {
    var_dump($this);
};

$foo->call(new Foo());

Independent of that, I would value the explicitness of needing to specify the static, because that would allow a clear path towards supporting non-static closures (e.g. for Attributes) in a follow-up.

I realize though that for properties we should require static for now. (unless you are going to provide properties with $this on new SomeClass...)

Yes. I already had a quick chat with @iluuu1994 about this and we agreed that requiring the closure to be static would be a good decision for the initial version of this feature.

[bwoebi]

@TimWolla Oh, yes, there's a difference between static and unbound. But is there any reason a top-level closure should not be unbound?
Like, why would you not permit:

class Foo {}
const CO = function () { var_dump($this); };
CO->call(new Foo);

The only problem is with Closures within classes.

[TimWolla]

But is there any reason a top-level closure should not be unbound?

I assume that would technically be supportable in the exact locations where a new expression would be legal?

Like, why would you not permit:

I believe that the usefulness of a top-level closure is very limited (why would you not write a regular function?). For my initial proposal I want to keep the feature easy to reason about (“closures in const-expressions must always be static”) and also keep the implementation simple(r).

[dstogov]

The patch looks good. I don't see problems, but I can't think about all possible consequences.

[iluuu1994]

It looks like zend_ast_get_lineno() lacks handling for ZEND_AST_OP_ARRAY.

Couldn't find any other issues.

[TimWolla]

It looks like zend_ast_get_lineno() lacks handling for ZEND_AST_OP_ARRAY.

Indeed it does. It appears to be unobservable as of now, since ZEND_AST_OP_ARRAY by itself is infallible, but this nevertheless is a bug.

[iluuu1994]

I missed this yesterday, but it seems you're missing support for file cache in ext/opcache/zend_file_cache.c. The rest LGTM.

[iluuu1994]

I see no more issues.