Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111594
MIME-Version: 1.0
References: <CAPyj-LCozQQEk8o2-Dse3Am+UEKYhEKSfUW3MWN-m6mdboNG=Q@mail.gmail.com>
 <92f3ee69-7b06-4995-546e-95f0218767bb@gmail.com>
In-Reply-To: <92f3ee69-7b06-4995-546e-95f0218767bb@gmail.com>
Date: Mon, 17 Aug 2020 19:53:55 +0200
Message-ID: <CAPyj-LD=9E3vQxLS9xYeUg7y30SQTYf3J3LWJ+E9JcEJYrOX8w@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Better string interpolation
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Rowan

> On 14/08/2020 17:14, Ilija Tovilo wrote:
>> I've been thinking about ways to improve string interpolation. String
>> interpolation in PHP is currently pretty limited to say the least.

Thanks for your feedback!

> we could take the opportunity to bring more features into the mix
>
> 1) modifiers; e.g. sprintf-style, f"Measure #0.2f{$value}" or
> template-style, f"Hello #{$name|escape}"

sprintf-style modifiers are an interesting idea. But I'm not sure if
there would be a huge advantage over using number_format.

I see two issues with template-style filters. 1. The syntax is
ambiguous: $name|escape could mean "pass $name to the filter escape"
or "bitwise-or $name and the constant escape". We could disambiguate
with a different symbol ($name|>escape). 2. This strongly overlaps
with the pipe operator (https://wiki.php.net/rfc/pipe-operator-v2).
Pipe operators would probably automatically solve this use case
(although the given filters still have to be added).

> 2) custom rules, like JavaScript's tagged templates [1], e.g. html"Hello
> #{$name}" == "Hello " . htmlspecialchars($name)

Escaping is a nice idea but I'm not sure we want to go that route.
String interpolation is still a bad fit for many templating things,
like rendering lists (although possible with implode and array_map) or
if statements (although possible with ternary and : ''). For some
things you might potentially not expect escaping at all (script tags,
style attributes, etc). I'm not completely opposed to the idea but
it's not something I'd personally be interested to work on.

> If we took JS tagged templates as the inspiration, that would de-sugar
> to something like:

Interesting, I didn't know about this feature. Honestly, I can't think
of many use cases on the spot. It's very possible this is just my
limited imagination.

Luckily if we decide not adding tagged templates at first there's
nothing stopping us from adding them at a later point in time. The
same goes with the html tagged templates above.

Ilija