rfc:arbitrary_expression_interpolation

This is an old revision of the document!


PHP RFC: Arbitrary Expression Interpolation

Introduction

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.

Proposal

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"

Syntax Choice

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 minor BC break
  • Sting sigils (such as: e“Result: {func()}”) - Poses no BC break, but is not really applicable to the execution operator or the heredoc syntax

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).

Backward Incompatible Changes

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

This will also mean that the # symbol will now need additional escaping in the context of double-quoted (or heredoc) strings used by regular expressions that use a # as the delimiter. For example:

preg_match("#Number \#[1-9][0-9]*#", $input);

In order for the above regular expression to work as expected, the # will need to be escaped, either by \\# or \\\#.

It's because of this issue with respect to regular expression usage that I have chosen to target the next major version of PHP.

Proposed PHP Version(s)

The next major version of PHP (PHP 8, or whatever it will be numbered).

RFC Impact

To Opcache

None that I'm aware of.

Proposed Voting Choices

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

Patches and Tests

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

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

Implementation

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)

References

Links to external references, discussions or RFCs

Rejected Features

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

rfc/arbitrary_expression_interpolation.1506354921.txt.gz · Last modified: 2017/09/25 15:55 by tpunt