# [RFC][Under discussion] Arbitrary string interpolation - Thread: https://externals.io/message/117363 - Original archive: https://news-web.php.net/php.internals/117363 - Started by Ilija Tovilo on 2022-03-17T22:27:30+00:00 - Messages: 22 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #117363 — Ilija Tovilo — 2022-03-17T22:27:30+00:00 URL: https://externals.io/message/117363#117363 Hi everyone I'd like to start discussion on a new RFC for arbitrary string interpolation. https://wiki.php.net/rfc/arbitrary_string_interpolation Let me know what you think. Ilija --- ## #117364 — Marco Pivetta — 2022-03-17T22:30:55+00:00 URL: https://externals.io/message/117363#117364 · In reply to: #117363 Hey Ilija, Overall not a fan: want more `sprintf()` and less interpolation, where possible 😬 Couldn't we let the construct slowly decay into nothingness, perhaps? > Hi everyone > > I'd like to start discussion on a new RFC for arbitrary string > interpolation. > https://wiki.php.net/rfc/arbitrary_string_interpolation > > Let me know what you think. > > Ilija --- ## #117365 — Tobias Nyholm — 2022-03-17T22:40:16+00:00 URL: https://externals.io/message/117363#117365 · In reply to: #117364 That is a cool idea. But I am not a big fan of having code in strings. Wouldn’t this open the door to all kinds of new attacks? // Tobias > > > Hey Ilija, > > Overall not a fan: want more `sprintf()` and less interpolation, where > possible 😬 > > Couldn't we let the construct slowly decay into nothingness, perhaps? > > > > > […] --- ## #117367 — Theodore Brown — 2022-03-18T04:49:21+00:00 URL: https://externals.io/message/117363#117367 · In reply to: #117365 > > > > […] > > That is a cool idea. > But I am not a big fan of having code in strings. > Wouldn’t this open the door to all kinds of new attacks? Do you have an example of a new kind of attack this would allow? The proposal doesn't enable interpolation of strings coming from a database or user input - it only applies to string literals directly in PHP code. Personally I'm really looking forward to having this functionality. Just a couple days ago I wanted to call a function in an interpolated string, and it was really annoying to have to wrap the function in a closure in order to use it. If this RFC is accepted I'd be able to replace code like this: $name = "Theodore Brown"; $strlen = fn(string $string): int => strlen($string); echo "{$name} has a length of {$strlen($name)}."; with $name = "Theodore Brown"; echo "{$name} has a length of {$:strlen($name)}."; Sincerely, Theodore --- ## #117368 — Robert Landers — 2022-03-18T08:55:45+00:00 URL: https://externals.io/message/117363#117368 · In reply to: #117363 I've wanted this for years! Robert Landers Software Engineer Utrecht NL On Thu, Mar 17, 2022 at 11:27 PM Ilija Tovilo wrote: > Hi everyone > > I'd like to start discussion on a new RFC for arbitrary string > interpolation. > https://wiki.php.net/rfc/arbitrary_string_interpolation > > Let me know what you think. > > Ilija > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #117372 — Chase Peeler — 2022-03-18T14:02:13+00:00 URL: https://externals.io/message/117363#117372 · In reply to: #117367 On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown wrote: > On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm > wrote: > > > […] > > Do you have an example of a new kind of attack this would allow? > The proposal doesn't enable interpolation of strings coming from > a database or user input - it only applies to string literals > directly in PHP code. > > Personally I'm really looking forward to having this functionality. > Just a couple days ago I wanted to call a function in an interpolated > string, and it was really annoying to have to wrap the function in a > closure in order to use it. > > If this RFC is accepted I'd be able to replace code like this: > > $name = "Theodore Brown"; > $strlen = fn(string $string): int => strlen($string); > echo "{$name} has a length of {$strlen($name)}."; > > with > > $name = "Theodore Brown"; > echo "{$name} has a length of {$:strlen($name)}."; > > Out of curiosity, why not: $name = "Theodore Brown"; echo "{$name} has a length of ".strlen($name)."."; or even $name = "Theodore Brown"; $len = strlen($name); echo "{$name} has a length of {$len}."; > > Sincerely, > > Theodore > -- > > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepeeler@gmail.com --- ## #117373 — Pierre — 2022-03-18T14:09:03+00:00 URL: https://externals.io/message/117363#117373 · In reply to: #117372 Le 18/03/2022 à 15:02, Chase Peeler a écrit : > On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown > wrote: > > > […] > Out of curiosity, why not: > $name = "Theodore Brown"; > echo "{$name} has a length of ".strlen($name)."."; > > or even > $name = "Theodore Brown"; > $len = strlen($name); > echo "{$name} has a length of {$len}."; I guess it's a matter of taste and convention. Sometime, it make sense and it's just easier to just use string interpolation (for example with multiline templates). Regards, -- Pierre --- ## #117375 — Paul Dragoonis — 2022-03-18T17:49:35+00:00 URL: https://externals.io/message/117363#117375 · In reply to: #117373 I think the original goal of this RFC is to make PHP more expressive, and less clunky (look at Jav). This is a good goal and one much desired by the community, but I think the approach here isn't the right fit or way to achieve it Writing code in strings is a DX nightmare, and static analysis challenge. PHP is improving onto a more verbose, typed, but exprsssive language, and this change would make that harder. I'm also thinking if this could become a LCE/RCE vulnerability in a type of eval() situation. Not a huge point but just an observation. Happy to re evaluate a new approach to solve the same problem that doesn't involve coding inside strings. > Le 18/03/2022 à 15:02, Chase Peeler a écrit : > > […] > wrote: > > […] > > I guess it's a matter of taste and convention. > > Sometime, it make sense and it's just easier to just use string > interpolation (for example with multiline templates). > > Regards, > > -- > > Pierre > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #117376 — Claude Pache — 2022-03-18T19:42:46+00:00 URL: https://externals.io/message/117363#117376 · In reply to: #117375 > Le 18 mars 2022 à 18:49, Paul Dragoonis a écrit : > > I think the original goal of this RFC is to make PHP more expressive, and > less clunky (look at Jav). This is a good goal and one much desired by the > community, but I think the approach here isn't the right fit or way to > achieve it > > Writing code in strings is a DX nightmare, and static analysis challenge. > > PHP is improving onto a more verbose, typed, but exprsssive language, and > this change would make that harder. > > I'm also thinking if this could become a LCE/RCE vulnerability in a type of > eval() situation. Not a huge point but just an observation. > > Happy to re evaluate a new approach to solve the same problem that doesn't > involve coding inside strings. Although I agree that code execution in strings is not a great idea, it should be noted that this is already possible today, so that this proposal does not add a new capability. Indeed, the proposed syntax: "{$:/* arbitrary expression here */}"; is equivalent to: $expr = fn($_) => $_; "{$expr(/* arbitrary expression here */)}"; —Claude --- ## #117377 — Hans Henrik Bergan — 2022-03-18T19:55:45+00:00 URL: https://externals.io/message/117363#117377 · In reply to: #117367 i'd write it as $name = "Theodore Brown"; echo "{$name} has a length of " . strlen ( $name ) . "."; > On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm > wrote: > > > […] > > Do you have an example of a new kind of attack this would allow? > The proposal doesn't enable interpolation of strings coming from > a database or user input - it only applies to string literals > directly in PHP code. > > Personally I'm really looking forward to having this functionality. > Just a couple days ago I wanted to call a function in an interpolated > string, and it was really annoying to have to wrap the function in a > closure in order to use it. > > If this RFC is accepted I'd be able to replace code like this: > > $name = "Theodore Brown"; > $strlen = fn(string $string): int => strlen($string); > echo "{$name} has a length of {$strlen($name)}."; > > with > > $name = "Theodore Brown"; > echo "{$name} has a length of {$:strlen($name)}."; > > > Sincerely, > > Theodore > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #117378 — Theodore Brown — 2022-03-18T22:01:18+00:00 URL: https://externals.io/message/117363#117378 · In reply to: #117372 > > > […] > > > Out of curiosity, why not: > > $name = "Theodore Brown"; > echo "{$name} has a length of ".strlen($name)."."; > > or even > > $name = "Theodore Brown"; > $len = strlen($name); > echo "{$name} has a length of {$len}."; Concatenation works fine for a simple example like this, but it can get a lot messier when there are more than a few embedded variables. It's particularly an issue with heredoc strings which are far more cumbersome to concatenate. Yes, it's possible to add extra variables before the string like in your second example, but this feels like unnecessary work, especially when you already have all the variables you want and just want to apply a function to them at several places in a template string. Theodore --- ## #117382 — Robert Landers — 2022-03-19T18:35:09+00:00 URL: https://externals.io/message/117363#117382 · In reply to: #117378 On Fri, Mar 18, 2022 at 11:01 PM Theodore Brown wrote: > > > […] > wrote: > > […] > > Concatenation works fine for a simple example like this, but it can > get a lot messier when there are more than a few embedded variables. > It's particularly an issue with heredoc strings which are far more > cumbersome to concatenate. > > Yes, it's possible to add extra variables before the string like in > your second example, but this feels like unnecessary work, especially > when you already have all the variables you want and just want to > apply a function to them at several places in a template string. > One function that I continuously run into is 'number_format' (and its intl equivalents). It'd be much easier to read "you have {$:number_format(count($items))} remaining" instead of "you have $formatted_count_of_items remaining" > Theodore > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #117385 — Rowan Tommins — 2022-03-20T13:39:47+00:00 URL: https://externals.io/message/117363#117385 · In reply to: #117375 > Writing code in strings is a DX nightmare Can you expand a bit on what you mean by that? It seems to be common to assert the opposite, that string interpolation is much more convenient than the alternatives. Looking around, it seems nearly all currently-popular languages include some form of interpolation. Notable languages which don't currently support it at all are Java and Go. Rust doesn't have a generic syntax, but some built-in macros support variable-only interpolation: https://blog.rust-lang.org/2022/01/13/Rust-1.58.0.html#captured-identifiers-in-format-strings Perl, from which PHP has largely inherited its string syntax, is actually more restrictive than most. Arbitrary expressions are just about possible with a bit of hackery, but not really encouraged: https://perldoc.perl.org/perlfaq4#How-do-I-expand-function-calls-in-a-string%3F All the other languages I looked at have support for full expressions in their interpolation forms: * C# - $"x + y = {x + y}" - https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated * Dart - 'x + y = ${x + y}' - https://api.dart.dev/stable/2.16.1/dart-core/String-class.html * JavaScript - `x + y = ${x + y}` - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals * Kotlin - "x + y = ${x + y}"  - https://kotlinlang.org/docs/basic-types.html#string-templates * Python - f'x + y = {x + y}' - https://peps.python.org/pep-0498/ * Raku (Perl6) - "\$x + \$y = { $x + $y }" - https://docs.raku.org/language/quoting.html#Interpolation:_qq * Ruby - "x + y = #{x + y}" - http://ruby-for-beginners.rubymonstas.org/bonus/string_interpolation.html * Scala - s"x + y = ${$x + $y}" - https://docs.scala-lang.org/overviews/core/string-interpolation.html * Swift - "x + y = \(x + y)" - https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html#ID292 Interestingly, a few languages have forms that combine arbitrary expression interpolation with printf-style modifiers. For instance, to format a float x to 3 decimal places, aligned right to width 10: * C# - $"{x,10:F3}" * Python - f"{x:10.3}" * Scala - f"$x%10.3f" It might be interesting to explore this for PHP, e.g. "{$:$x:10.3f}". If we're not sure we want it yet, we could leave the option open by making anything of the form "{$:expression:format}" a syntax error. Using a second colon would make ternary expressions slightly awkward; C# handles this by requiring them to be parenthesised, so "{$:( $test ? $x : $y )}" would be valid but "{$:$test ? $x : $y}" would not; we could use some other delimiter, but they'd probably all need something similar. PS: Reminder to all that convention on this list is to reply below not above quoted text. -- Rowan Tommins [IMSoP] --- ## #117388 — Rowan Tommins — 2022-03-21T09:51:15+00:00 URL: https://externals.io/message/117363#117388 · In reply to: #117385 > Using a second colon would make ternary expressions slightly awkward; > C# handles this by requiring them to be parenthesised, so "{$:( $test > ? $x : $y )}" would be valid but "{$:$test ? $x : $y}" would not; we > could use some other delimiter, but they'd probably all need something > similar. Thinking about it, a second colon might also cause problems for expressions like "{$: Foo::bar() }", so since we have multiple symbols at the start anyway, how about a prefixed formatting argument, e.g. "{$%10.3f: $x }" Regards, -- Rowan Tommins [IMSoP] --- ## #117389 — Robert Landers — 2022-03-21T10:27:56+00:00 URL: https://externals.io/message/117363#117389 · In reply to: #117388 On Mon, Mar 21, 2022 at 10:51 AM Rowan Tommins wrote: > > > […] > > > Thinking about it, a second colon might also cause problems for > expressions like "{$: Foo::bar() }", so since we have multiple symbols > at the start anyway, how about a prefixed formatting argument, e.g. > "{$%10.3f: $x }" > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php > > The downside of a prefix is that it isn't backwards compatible. You could use # in a suffix so if you need to write backwards compatible code, you can. So maybe: echo "{$x#10.3f}"; which can be written like this in backwards compatible code: echo "{$x#10.3f }"; It isn't pretty, but it's better than a parse error and things like Rector could do this automatically. --- ## #117390 — Rowan Tommins — 2022-03-21T12:23:08+00:00 URL: https://externals.io/message/117363#117390 · In reply to: #117389 > The downside of a prefix is that it isn't backwards compatible. You could use # in a suffix so if you need to write backwards compatible code, you can. So maybe: > > echo "{$x#10.3f}"; > > which can be written like this in backwards compatible code: > > echo "{$x#10.3f > }"; That's a neat trick, although I'm surprised comments are allowed in that position given expressions in general aren't. I think being a syntax error in previous versions is a good thing though; falling back to ignoring the formatting specifier could result in unexpected behaviour, maybe even leaking data that the formatting was intended to hide, and projects which need to support multiple PHP versions are more likely to simply use `sprintf()` to get the same output on all versions. I was also deliberately pairing it with the arbitrary expression syntax as one new feature, so that we don't have so many combinations to explain to new users ("$x", "{$x}", "{$: $x}", "{$x#10.3f}", "{$: $x #10.3f}") Regards, -- Rowan Tommins [IMSoP] --- ## #117426 — Arnaud Le Blanc — 2022-03-25T14:38:08+00:00 URL: https://externals.io/message/117363#117426 · In reply to: #117363 Hi Ilija I find that `sprintf()` is easier to read in most cases. One reason for this is that the text is separated from the code. It's also easier to review for humans and linters. The strtoupper example would look like this with sprintf: $world = 'world'; echo sprintf('Hello %s!', strtoupper($world)); Longer examples can be nicely split in multiple lines: echo sprintf( 'Received HTTP status code %d (reason phrase: %s)', $response->getStatusCode(), $response->getReasonPhrase(), ); And this also works with heredoc: echo sprintf( <<<'HTML' %s HTML, htmlspecialchars($title), ); -- Arnaud On jeudi 17 mars 2022 23:27:30 CET Ilija Tovilo wrote: > Hi everyone > > I'd like to start discussion on a new RFC for arbitrary string > interpolation. https://wiki.php.net/rfc/arbitrary_string_interpolation > > Let me know what you think. > > Ilija --- ## #117427 — Andreas Heigl — 2022-03-25T15:43:33+00:00 URL: https://externals.io/message/117363#117427 · In reply to: #117426 Hey Ilija. > Hi Ilija > > I find that `sprintf()` is easier to read in most cases. One reason for this is > that the text is separated from the code. It's also easier to review for > humans and linters. > > The strtoupper example would look like this with sprintf: > > $world = 'world'; > echo sprintf('Hello %s!', strtoupper($world)); > > Longer examples can be nicely split in multiple lines: > > echo sprintf( > 'Received HTTP status code %d (reason phrase: %s)', > $response->getStatusCode(), > $response->getReasonPhrase(), > ); This technique also allows me to use the original string in translation while still keeping the replacements out of that. So something like echo sprintf( gettext('Hello %s!'), strtoupper($world) ); would easily work and provide the translator only with the string `Hello %s` which is much less to break than `Hello {strtoupper($world)}!` So for internationalized applications I'd rather keep the sprintf approach than a new string-syntax. A way to use sprintf in a more out-of-the-box way like in ruby would be awesome! Something like echo 'Hello %s' % [strtoupper($world)]; or echo 'Hello %{world}' % ['world' => strtoupper($world)]; But I'm absolutely happy with the current sprintf functionality. Just my 0.02€ Cheers Andreas -- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --- ## #117433 — Rowan Tommins — 2022-03-26T22:15:01+00:00 URL: https://externals.io/message/117363#117433 · In reply to: #117426 > I find that `sprintf()` is easier to read in most cases. One reason for this is > that the text is separated from the code. Funnily enough, I find `sprintf()` *harder* to read for the same reason - particularly once there are more than two or three parameters, and more than a bit of punctuation between them. A large part of that is because the placeholders are positional rather than named, so you have to keep track of which is which; but by the time you've got named placeholders, you might as well have variable interpolation. As a silly example, I prefer this: $sentence = "The {$adjectives[0]} {$adjectives[1]} {$nouns[0]} jumped over the {$adjectives[2]} {$nouns[1]}"; To this: $sentence = sprintf(    'The %s %s %s jumped over the %s %s',    $adjectives[0],    $adjectives[1],    $nouns[0],    $adjectives[2],    $nouns[1] ); I think that's partly a matter of taste, though, because I've definitely seen people happily using both styles. And there are certainly situations (like translation strings) where placeholders of some sort work better than straight interpolation. That's why I thought it was interesting to see what other languages have done. While PHP and Ruby have obvious links back to Perl, many languages which didn't start off with string interpolation have added it in later versions, e.g. C#, Scala, JavaScript, Python. Clearly there were sufficient voices in favour in each of those communities to add it; and in each case, they added *expression* interpolation, not just the *variable* interpolation supported by Perl and PHP. I won't be too upset if this feature doesn't get added, but I do think it would be a nice addition. Regards, -- Rowan Tommins [IMSoP] --- ## #117436 — Ilija Tovilo — 2022-03-27T16:41:03+00:00 URL: https://externals.io/message/117363#117436 · In reply to: #117433 > All the other languages I looked at have support for full expressions in > their interpolation forms: Thank you Rowan, I added the comparison of other languages to the RFC. > A large part of that is because the placeholders are positional rather > than named, so you have to keep track of which is which; but by the time > you've got named placeholders, you might as well have variable > interpolation. I feel the same way. PHPStorm has a feature that highlights the given expression when your cursor is placed on a %s placeholder and vice versa. This seems to be the treatment of that symptom. > and in each case, they added *expression* interpolation, not just the > *variable* interpolation supported by Perl and PHP. Also note that the goal of this RFC is not to encourage embedding increasingly complex expressions in strings, but rather to allow simple expressions like string manipulation and constants. Could you now declare all your classes in a string? Yes. Can you create a 20'000 line PHP file? Sure. I don't think most people would support some arbitrary cutoff for LOC either. As Rowan mentioned, most languages allow expressions in strings and yet this is rarely abused in practice. > Wouldn’t this open the door to all kinds of new attacks? No. It's no different from `"$userControllerString"`. Make sure to sanitize user-controlled input. The expression inside the string is parsed at compile-time, something like `"{$: $userControlledString}"` where `$userControlledString = 'doSomethingBad()';` will *not* interpret that string and call that function but rather just result in `"doSomethingBad()"`. Another thing I'd like to mention: All the heavy lifting for full blown expression string interpolation is already there. If you look at the implementation (https://github.com/php/php-src/pull/8256) very few changes are necessary to make this work. Ilija --- ## #117438 — Guilliam Xavier — 2022-03-28T13:22:22+00:00 URL: https://externals.io/message/117363#117438 · In reply to: #117436 Hi, > A large part of that is because the placeholders are positional rather > > […] > > I feel the same way. PHPStorm has a feature that highlights the given > expression when your cursor is placed on a %s placeholder and vice > versa. This seems to be the treatment of that symptom. > Has "add named placeholders to *printf()" been proposed/discussed before (I didn't find)? What about `strtr()` (e.g. `strtr('The {foo} is {bar}.', ['{foo}' => FOO, '{bar}' => bar()])`)? (and even templating engines like Twig?) Anyway, it sometimes baffles me indeed that I can build a string with a method call like `"...{$foo->bar()}..."` but not with a function call like `"...{foo($bar)}..."`, and also with complex interpolation via callable variable like `"...{$foo($bar + baz($qux))}..."` but not with simple constant like `"...{FOO}..."` or operation like `"...{$foo + 1}..."` :/ Regards, -- Guilliam Xavier --- ## #117476 — MKS Archive — 2022-04-05T01:57:49+00:00 URL: https://externals.io/message/117363#117476 · In reply to: #117433 > > > > > […] > > > Funnily enough, I find `sprintf()` *harder* to read for the same reason - particularly once there are more than two or three parameters, and more than a bit of punctuation between them. > > A large part of that is because the placeholders are positional rather than named, so you have to keep track of which is which; but by the time you've got named placeholders, you might as well have variable interpolation. > > As a silly example, I prefer this: > > $sentence = "The {$adjectives[0]} {$adjectives[1]} {$nouns[0]} jumped over the {$adjectives[2]} {$nouns[1]}"; > > To this: > > $sentence = sprintf( > 'The %s %s %s jumped over the %s %s', > $adjectives[0], > $adjectives[1], > $nouns[0], > $adjectives[2], > $nouns[1] > ); > > I think that's partly a matter of taste, though, because I've definitely seen people happily using both styles. And there are certainly situations (like translation strings) where placeholders of some sort work better than straight interpolation. Choice of `sprintf()` vs string interpolation *can* be more than a matter of taste, and this from someone who once greater preferred the latter. There are (at least) two use-cases I am familiar with where using `printf()` and `sprintf()` with placeholders have benefits over string interpolation. 1.) Internationalization of human-readable strings can be more easily facilitated when the literal text is kept distinct from the interpolated values. 2.) Reduced memory allocation and string manipulation when strings are used for logging that may be discarded when logging levels are set to less than "log everything." #fwiw > That's why I thought it was interesting to see what other languages have done. While PHP and Ruby have obvious links back to Perl, many languages which didn't start off with string interpolation have added it in later versions, e.g. C#, Scala, JavaScript, Python. Clearly there were sufficient voices in favour in each of those communities to add it; and in each case, they added *expression* interpolation, not just the *variable* interpolation supported by Perl and PHP. > > I won't be too upset if this feature doesn't get added, but I do think it would be a nice addition. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php