PHP: rfc:arbitrary_expression_interpolation

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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

===== 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:

<code php>
$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"
</code>

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

===== Backward Incompatible Changes =====
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}~"''.

===== Proposed PHP Version(s) =====
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.

===== 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 
  - the version(s) it was merged to
  - a link to the git commit(s)
  - a link to the PHP manual entry for the feature
  - 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.
Page Tools
