String Templates: syntax question

[Brian Goetz]

On 11/12/2023 4:42 PM, Eran Leshem wrote:
>
> Hello,
>
> I’m delighted by the addition of String Templates to Java!
>
> I have a question about the syntax. The Alternatives section of the 
> JEP gives great answers to most questions, but I was left with this one:
>
> Why is the backslash needed? In most languages, as you nicely listed, 
> string templates are marked with either a template prefix or an 
> embedded expression prefix. Why does Java require both the 
> “<processor>.” template prefix and the “\” embedded expression prefix?
>

There were a number of reasons for this choice, which was made in the 
light of the many different choices other languages have made (and their 
pros and cons) and the consequences for _adding_ this as a feature to 
Java (as opposed to if it had been part of the language from day 1.)

One proximate reason is uniformity and migration; Java programs are full 
of string literals today (which are sometimes used as templates for 
String::format and the like), and many of them have dollar signs 
already.  And a string literal / text block with _no_ embedded 
expressions can still be used in a template expression, and means the 
obvious thing, and this is both uniform and useful.  If all strings 
_except those with dollar signs_ were valid in template expressions, but 
dollar signs had to be escaped, this means migrating existing code to 
use template expressions forces the user to scan the entirety of their 
string (which could be many lines long) to search for dollar signs and 
escape them, or risk making a mistake.  That's terrible, and unnecessary.

While it might be possible to rescue the ${blah} syntax if it were 
indeed great, in actually this syntax is terrible; we're all just so 
used to it that we've stopped seeing how awful it is.  The $ character 
is common in strings, which makes this error prone (using $ instead of 
\$ or however it would be escaped) and also means that strings with 
dollar signs are less readable.  A string literal is supposed to be a 
sequence of characters; while every string literal feature needs some 
sort of escape mechanism to handle non-printable characters, having two 
different escape mechanisms ($ for interpolation, \ for weird 
characters), each with their own special rules, is unnecessarily 
irregular.  It was not worth doing any work to rescue this syntax, just 
because it is familiar from some other languages.  We have an escape 
mechanism, which was easily extendible to this approach (and Swift's 
experience shows that the \{...} mechanism is perfectly usable.)

I can sort of see how you might want to characterize the processor as a 
"template prefix", but it is not; it is something else.  The template 
expression syntax is built on the string literal / text block syntax, 
and adding extra complexity just to rescue a fatally flawed (albeit 
familiar) syntax would have been a bad choice.

> The Ensuring Safety section implies that the backslash’s goal is to 
> enable the detection of string templates with missing processors. Did 
> I read that correctly? If so, I’d suggest documenting that explicitly. 
> In addition, I’d like to raise the question whether the extra ceremony 
> is warranted by that goal.
>

That was not the "goal"; it is merely one of its benefits.  The main 
reason to prefer backslash here is that strings _already have an escape 
mechanism_, and we should use the existing escape mechanism rather than 
inventing a new and different one.  This guarantees that existing 
strings can be used seamlessly with the new feature; it minimizes 
linguistic complexity and the activation energy of learning the 
language; and it reduces errors.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231112/2eb78981/attachment.htm>