Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision |
rfc:arbitrary_expression_interpolation [2017/09/22 13:28] – external edit 127.0.0.1 | rfc:arbitrary_expression_interpolation [2017/11/27 12:03] – 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, 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 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). 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 ===== |