PHP RFC: Arbitrary Expression Interpolation

• Version: 0.9
• Date: 2017-09-10
• Author: Thomas Punt, tpunt@php.net
• Status: Draft
• First Published at: https://wiki.php.net/rfc/arbitrary_expression_interpolation

Interpolation is a widely used feature in PHP. It is, however, constrained to variable-like expressions only, which makes its usage somewhat limited. I would therefore like to propose for the ability to interpolate arbitrary expressions in PHP.

This proposal introduces a new interpolation syntax: #{}. Any expression within the parentheses will be evaluated and stringified, concatenating it to the rest of the string. This change affects double-quoted strings, heredocs, and the execution operator (shell execution via backticks).

This will:

• Give greater flexibility to developers when constructing strings from any expressions
• Make heredocs a more useful feature, since they will not be constrained to evaluating variable-like expressions only

Some examples:

$value = 10;
 
function someFunc()
{
    return "def";
}
 
var_dump(
    "Result: #{$value * 5}", // string(10) "Result: 50"
    "abc #{someFunc()}", // string(7) "abc def"
    `echo #{$value * 5}` // string(3) "50\n"
);
 
echo <<<END
    Result: #{$value * 5}
END; // "    Result: 50"

There were a few different candidates regarding the syntactic choice, including:

• ${} - Poses a very large BC break, since ${a} would now look for a constant (rather than a variable) named a
• {} - Poses a potentially large BC break by suddenly giving all curly braces in strings semantic meaning
• #{} - Poses a low BC break
• Sting sigils (such as: e“Result: {func()}”) - Poses no BC break, but looks odd to apply to the execution operator (e`...`), and looks ugly for the heredoc syntax (e<<<END or e<<<“END”)

Overall, I have chosen the #{} syntax for its low BC impact, as well as its familiarity (given that the same syntax is used by other languages, including Ruby, Crystal, Elixir, and CoffeeScript).

The new syntax will now cause the character sequence #{...} to be evaluated within strings.

To minimise the BC impact, the # symbol will not need additional escaping (unlike the $ symbol) when used within interpreted (double-quoted/heredoc/execution operator) strings. This means that regular expressions such as “#Number \#[1-9][0-9]*#” can remain unaffected. However, there are still two cases where BC will be broken.

The first is by the consuming of the # in cases where a variable is interpolated with curly braces immediately following it, such as in “#{$n}”. In this case, the output will now not contain the leading # (it will need to be escaped as “\#{$n}”).

The second is that in the event a regular expression specifies a quantity of #s, such as “~#{1,2}~”, and this regular expression is encapsulated in evaluated strings, then it will now need to be escaped to “~\#{1,2}~”.

I have tentatively chosen the next major version of PHP (PHP 8, or whatever it will be numbered) for this feature. This is mainly due to the potential BC break with respect to regular expressions.

None that I'm aware of.

A simple yes or no for this feature (with a 2/3 majority required).

Initial implementation: https://github.com/php/php-src/compare/master...tpunt:arbitrary-expression-interpolation

Language specification: will be updated if the RFC is accepted.

After the project is implemented, this section should contain

1. the version(s) it was merged to
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature
4. a link to the language specification section (if any)

Links to external references, discussions or RFCs

Keep this updated with features that were discussed on the mail lists.