rfc:arbitrary_expression_interpolation

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:arbitrary_expression_interpolation [2017/09/15 22:22] tpuntrfc:arbitrary_expression_interpolation [2017/12/12 17:09] (current) tpunt
Line 42: Line 42:
   * ''${}'' - Poses a very large BC break, since ''${a}'' would now look for a constant (rather than a variable) named ''a''   * ''${}'' - 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 potentially large BC break by suddenly giving all curly braces in strings semantic meaning
-  * ''#{}'' - Poses a minor BC break+  * ''#{}'' - 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 familiaritygiven that the same syntax is used by some other languages too (Ruby, Crystal, Elixir, CoffeeScript).+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 =====
rfc/arbitrary_expression_interpolation.1505514134.txt.gz · Last modified: 2017/09/22 13:28 (external edit)