Repository navigation
Partially support first-class callable syntax in constant expressions #9236
Description
Description
The first-class callable syntax is currently not allowed in constant expressions:
class X {
const FN = strlen(...);
}
var_dump((X::FN)('test'));
// PHP Fatal error: Constant expression contains invalid operationsI propose partially supporting the first-class callable syntax in a constant expression. Specifically, I propose that PHP allows these two cases in a constant context:
class X {
const A = strlen(...);
const B = SomeClass::someStaticMethod(...);
}While (still) disallowing expressions that cannot be known at compile time:
class X {
const C = $closure(...);
const D = $obj->method(...);
const E = ($obj->property)(...);
// etc. See the first-class callables RFC for a complete list
}Example
Symfony's Choice assertion allows the user to specify a callback. It would be nice if we could use the first-class callable syntax in attributes, but this is currently not allowed:
use Symfony\Component\Validator\Constraints as Assert;
class User {
#[Assert\Choice(callback: Role::values(...))] // Using this syntax here causes an error
public string $role;
}
enum Role: string
{
case Customer = 'customer';
case Admin = 'admin';
public static function values() {
return array_map(fn (Role $a) => $a->name, self::cases());
}
}Implementation
I hacked together a working patch that supports the strlen(...) syntax in constant expressions. I haven't gotten around to implementing SomeClass::someStaticFunction(...) yet. There are probably some edge cases that I'm missing - I'm not too familiar with the PHP code base.
I'm also not sure if this feature would require an RFC. I would imagine it would, though.
Please let me know what you think.
Activity
cmb69 commentedon Aug 3, 2022
Yeah, I think there should be an RFC to discuss and clarify the details. Note that there is also #8959 which is a more general feature request.
github-actions commentedon Nov 2, 2022
There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.
gnumoksha commentedon Nov 9, 2022
Please, Mr Bot, don't close this :)
cmb69 commentedon Nov 9, 2022
See https://wiki.php.net/rfc/howto, if you're interested in pursuing this.
mvorisek commentedon Nov 10, 2022
I expect this to be fixed by #9301no RFC proposed yetbwoebi commentedon Nov 10, 2022
@mvorisek Not sure what you are referring to. That PR is about
staticvariables in functions, not constant expressions in general.github-actions commentedon Feb 9, 2023
There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.
mvorisek commentedon Mar 11, 2023
Any CTE expression like
strlen- https://3v4l.org/08SOl - should be supported in constant expression.KapitanOczywisty commentedon Mar 11, 2023
If function would be mistakenly added to CTE, but would be causing errors, you can just remove it in the next patch version and no one will notice. Removing function from constant expression would cause breaks. Then as an user, how do you even keep track which function are available for constant expressions? I could also imagine that this would require significant rework to implement.
github-actions commentedon Jun 10, 2023
There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.
dynasource commentedon Feb 21, 2024
+1