Straw poll: Places to allow function calls in constant expressions

Consequently, the only way to safely initialize class constants and static
members is at run-time, and I can only think of one way to do it. Apologies
if this has already been suggested: taking a cue from C#, a static class
constructor ([1]) would allow us to have expression-initialized constants
and static members.

<?php
class Config {
public const URL = null; // compile time initialization
protected static $mtime = null; // compile time initialization
private static function __constructStatic() {
$env = json_decode(file_get_contents('config.json'));
self::URL = $env->url;
self::$mtime = filemtime('config.json');
}
public function reload() {
if (self::$mtime < filemtime('config.json'))
self::__constructStatic();
}
}
}

echo Config::URL; // assert: runtime has already called _constructStatic
$config = new Config; // assert: __constructStatic called only once by
runtime
$config->reload(); // instance may call its own static constructor
?>

Trying to do the same for global constants, static variables, or function
default parameters resists a similar initialization mechanism because we
don't have defined common entry point analogues. If we had a main(), or if
we had framed @before decorators, we could do something similar, but we
don't -- so I feel we should leave these off the table.

For different reasons than this RFC I have wanted a static class constructor for a really long time.

I hope this is something we can seriously consider. Thanks Bishop for proposing it.

-Mike

The original motivation was, IIRC, to initialize class constants with an expression.
Following KISS, I feel we should constrain our efforts to that scope, and that's how I voted:
"Yes" on class constants and static members, "No" on everything else.

I'd also personally found the static $x = null; if ($x === null) { $x = some_fn(); } pattern inconvenient and wanted that to be just static $x = some_fn(); to make the initial value some_fn() if possible. It also seemed more readable (e.g. doesn't matter if some_fn() can be constant).

My personal use case for parameter defaults and global constants isn't as strong (especially with define()),
but it's still something I'd want.

• I'd be able to use private const FOO_DEFAULT = array_keys(...); function foo($x = FOO_DEFAULT) {} if constants did pass, so that's less off a concern, and ensures&makes clear that the expression is only evaluated once, so it might be a better place to start with.

As for implementation, we must manage the complexity.
I'm a hard "No" on restricting use to an arbitrary, variable list of blessed functions.
It's a dev UX nightmare to include a bevy of array_* functions but no str* functions.

If the RFC succeeded with a whitelist, I'd planned to create RFCs to add to the whitelist.
Locale dependency of string functions was the reason for leaving it out initially, since that may also be a hard "no" for others.

Consequently, the only way to safely initialize class constants and static members is at run-time, and I can only think of one way to do it.
Apologies if this has already been suggested: taking a cue from C#, a static class constructor ([1])
would allow us to have expression-initialized constants and static members.
<?php
class Config {
public const URL = null; // compile time initialization
protected static $mtime = null; // compile time initialization
private static function __constructStatic() {
$env = json_decode(file_get_contents('config.json'));
self::URL = $env->url;
self::$mtime = filemtime('config.json');
}
public function reload() {
if (self::$mtime < filemtime('config.json'))
self::__constructStatic();
}
}
}

echo Config::URL; // assert: runtime has already called _constructStatic
$config = new Config; // assert: __constructStatic called only once by runtime
$config->reload(); // instance may call its own static constructor
?>

This seems to allow the same functionality my RFC would allow, in a slightly different way.
I didn't go with that syntax because it'd move the values of the constants/properties away from the declaration.
Also, if json_decode() threw, then there would never be a way for a PHP implementation to initialize self::$mtime in that example, even though they're unrelated in how they're initialized there.
Allowing calling __constructStatic multiple times (thus assigning to the const self::URL multiple times) would be a significant change to php internals, and out of the scope of this RFC

https://wiki.php.net/rfc/calls_in_constant_expressions_poll ("Put the RFC(Poll) URL into all your replies.")

• Tyson