rfc:arbitrary_expression_interpolation

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
rfc:arbitrary_expression_interpolation [2017/11/27 12:03]
tpunt
rfc:arbitrary_expression_interpolation [2017/12/12 17:09] (current)
tpunt
Line 43: Line 43:
   * ''​{}''​ - 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 low BC break   * ''#​{}''​ - 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...+  * 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). 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).
Line 50: Line 50:
 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.+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 such as ''"#​{$n}"'', ​where the output will now not contain the leading ''#''​.+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}~"'', ​then this will now need to be escaped to ''"​~\#​{1,​2}~"''​.+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) =====
-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.+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 ===== ===== RFC Impact =====
rfc/arbitrary_expression_interpolation.txt · Last modified: 2017/12/12 17:09 by tpunt