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
Next revisionBoth sides next revision
rfc:arbitrary_expression_interpolation [2017/09/11 10:51] – created tpuntrfc:arbitrary_expression_interpolation [2017/09/25 15:55] – 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 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 ===== ===== 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.
 +
 +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:
 +<code php>
 +preg_match("#Number \#[1-9][0-9]*#", $input);
 +</code>
 +
 +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) ===== ===== Proposed PHP Version(s) =====
-The next PHP 7.x version (or 8.0, whichever comes next)+The next **major** version of PHP (PHP 8, or whatever it will be numbered).
  
 ===== 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.txt · Last modified: 2017/12/12 17:09 by tpunt

Page Tools