> As you've already realized, the main problem here is the behavior for
> functions that have side-effects or state. Currently we mostly get away
> with the illusion that it doesn't matter when exactly constexpr
> initializers are evaluated. Apart from the error location and (admittedly
> quite a
On Sun, Feb 2, 2020 at 12:00 AM tyson andre
wrote:
>
> Hi internals,
>
> I have a working implementation for calling global functions in constant
> expressions at https://github.com/php/php-src/pull/5139
> (see PR description for more details, see tests for how edge cases get
> resolved)
>
> If
Hi!
> The constant expressions will be evaluated at the same time php currently
> evaluates constant
> expressions.
But you essentially propose running arbitrary code at that time, which
is much bigger deal than evaluating simple constant expressions. While
simple functions like strlen() would
> What happens if a function like strlen() is applied to a non-string
> argument? Conversion to string is certainly runtime-dependent even for
> primitive types like floats.
Good point. I thought that string casts were already allowed, but was mistaken.
It's possible to cast to string through
Hi!
> For example, allow `\count()`, `\strlen()`, `\array_merge()`, and
> `\in_array()`,
> but don't allow functions such as
> `\strtolower()` (different in Turkish locale),
What happens if a function like strlen() is applied to a non-string
argument? Conversion to string is certainly
Hi internals,
I have a working implementation for calling global functions in constant
expressions at https://github.com/php/php-src/pull/5139
(see PR description for more details, see tests for how edge cases get resolved)
If there was interest, and no implementation or process blockers I
