Allow class constants in strings

[KapitanOczywisty]

Description

Strings should allow class constants (and class) https://3v4l.org/hTnNv

<?php
echo "{$foo::$Bar}\n"; // ok
echo "{$foo::Bar}\n"; // parse error
echo "{$foo::class}\n"; // parse error

[iluuu1994]

@KapitanOczywisty See master...iluuu1994:php-src:lift-variable-restriction-for-brace-dollar-string-interpolation, this would require a trivial adjustment in the grammar. But it is a language change.

[KapitanOczywisty]

@iluuu1994 I've stumbled upon RFC: Arbitrary string interpolation (thanks for making that RFC) and after reading a discussion I don't think restriction will be lifted any time soon for expressions, but I'm hoping at least constants could be supported.

[iluuu1994]

@KapitanOczywisty Note that these are two different ideas. The RFC suggests introducing a new interpolation variant that allows all expressions. The PR I linked above uses the existing {$ syntax to allow all expressions after that token. The reason the RFC wasn't received well is mostly that people didn't like the {$: syntax (which isn't what is being used here).

[KapitanOczywisty]

The reason the RFC wasn't received well is mostly that people didn't like the {$: syntax (which isn't what is being used here).

@iluuu1994 And also printf/concat/variable/$expr is better, static analysis will be harder etc. Linked commit would defacto implement RFC with inconvenient prefix $_= e.g. {$_=strlen($foo)}. Though {$=expr} wouldn't be that bad (similar to <?=...?>).

[KapitanOczywisty]

Potential fix/implementation for this issue: KapitanOczywisty@551ec3d

[iluuu1994]

Both of these are language changes, so why arbitrarily limit the allowed expressions?

Anyway, I'm not against adding this. But we should at least consult the mailing list 🙂

[KapitanOczywisty]

why arbitrarily limit the allowed expressions?

I'd prefer to support any expression, but as a fallback class constants could be added.

we should at least consult the mailing list 🙂

For now I don't have email to expose for the whole world, so I can't do that.

[mvorisek]

I do not think any expression should be allowed, as such expressions can allow writing long code inside strings. And modify VM state like $a = strtolower($a). But I agree class/any constants/enum values should be allowed.

[iluuu1994]

You can already do those things if you really want, e.g. in function arguments.

[KapitanOczywisty]

I've dug up old hack from stackoverflow which uses variable without the name to write expressions:

echo "Test {${!${''} = strtoupper('foo')}}.";

That train has sailed a long time ago.

[Digitalone1]

So at the moment the only way to interpolate a class/trait constant into a string is to copy it into a variable and interpolate the variable, right?

At least I hope the compiler would be smart enough to understand that the variable does not change and copy only the reference/pointer, not the entire string, otherwise this would be overkill.

Please fix this, because having to concatenate a constant with dots only because the interpolation is not supported is a big drawback, especially when you have very large strings with heredoc syntax.

[mindaugasvcs]

All modern languages can do it except PHP.
P.S. Java obviously is not modern :)

[Digitalone1]

All modern languages can do it except PHP. P.S. Java obviously is not modern :)

It's weird. I assume it's because you can't use a leading $ to reference a constant inside a class/trait. Indeed you have to write self::CONST_NAME.

So I would suggest allowing $this::CONST_NAME. If I can reference a variable with this pointer, why shouldn't I do the same for a constant?

One could say, because self is not a pointer and does not reference the current class instance. Well, I could still access a constant outside the class using the pointer (of the instance, see this: https://3v4l.org/5hsZ4#v8.4.3), but I can't interpolate it into a string anyway.