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
Last revisionBoth sides next revision
rfc:arbitrary_expression_interpolation [2017/09/11 10:51] – created tpuntrfc:arbitrary_expression_interpolation [2017/11/27 12:03] – 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 is not really applicable to the execution operator, looks ugly for the heredoc syntax, and introduces a "conditionally activated" 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.
 +
 +To minimise the BC impact, the ''#'' symbol will **not** need additional escaping (unlike the ''$'' symbol). 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 such as ''"#{$n}"'', where the output will now not contain the leading ''#''.
 +
 +The second is that in the event a regular expression specifies a quantity of ''#''s, such as ''"~#{1,2}~"'', then this 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.0, whichever comes next)+I have tentatively chosen the next **major** version of PHP (PHP 8, or whatever it will be numbered) for this feature. This is 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.txt · Last modified: 2017/12/12 17:09 by tpunt

Page Tools