rfc:arbitrary_expression_interpolation

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
rfc:arbitrary_expression_interpolation [2017/09/11 10:51] – created tpuntrfc:arbitrary_expression_interpolation [2017/12/12 17:09] (current) tpunt
Line 20: Line 20:
 <code php> <code php>
 $value = 10; $value = 10;
-var_dump("Result: #{$value * 5}"); // string(10) "Result: 50" 
  
-function a()+function someFunc()
 { {
     return "def";     return "def";
 } }
  
-var_dump("abc #{a()}"); // string(7) "abc def" +var_dump( 
- +    "Result: #{$value * 5}", // string(10) "Result: 50" 
-`echo #{$value * 5}`// 50+    "abc #{someFunc()}"// string(7) "abc def" 
 +    `echo #{$value * 5}` // string(3) "50\n" 
 +);
  
 echo <<<END echo <<<END
-Result: #{$value * 5} +    Result: #{$value * 5} 
-END; // "Result: 50"+END; // "    Result: 50"
 </code> </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 ===== ===== Backward Incompatible Changes =====
 The new syntax will now cause the character sequence ''#{...}'' to be evaluated within strings. 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) ===== ===== Proposed PHP Version(s) =====
-The next PHP 7.x version (or 8.0whichever comes next)+I have tentatively chosen the next **major** version of PHP (PHP 8, or whatever it will be numberedfor this feature. This is mainly due to the potential BC break with respect to regular expressions.
  
 ===== RFC Impact ===== ===== RFC Impact =====
  
 ==== To Opcache ==== ==== To Opcache ====
-Still need to be checked.+None that I'm aware of.
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
-A simple yes or no for this feature (with a 2/3 +1 majority required).+A simple yes or no for this feature (with a 2/3 majority required).
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
rfc/arbitrary_expression_interpolation.1505127080.txt.gz · Last modified: 2017/09/22 13:28 (external edit)