| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| rfc:arbitrary_expression_interpolation [2017/09/25 15:55] – tpunt | rfc:arbitrary_expression_interpolation [2017/12/12 17:09] (current) – tpunt |
|---|
| * ''${}'' - 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 is not really applicable to the execution operator or the heredoc 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). |
| 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: | 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. |
| <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 ''\\\#''. | 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}"''). |
| |
| It's because of this issue with respect to regular expression usage that I have chosen to target the next major version of PHP. | 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 **major** version of PHP (PHP 8, or whatever it will be numbered). | 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 ===== |