Update on String Templates (JEP 459)

[Maurizio Cimadamore]

Hi

On 15/03/2024 16:07, Guy Steele wrote:

> Then again, now that I ponder the space of use cases, it may be that, 
> despite my initial enthusiasm, having a separate string interpolation 
> syntax may not carry its weight if its uses are relatively rare. We 
> always have the option of using a string template and then applying an 
> interpolation processor (which might be spelled 
> `String.of(<template>)` or `(<template>).interpolate()` or some other 
> way), and about all we lose from that approach is the ability to use 
> string interpolation to specify a constant expression—for which we 
> still have the old-fashioned alternative of using `+` concatenation. 
> If we drop string interpolation, we can then drop the INTERPOLATION 
> prefix, and we are back to a single-prefix model, and the remaining 
> question is whether that prefix is optional, at least in some cases. 
> Okay, I think I now have a better understanding of the relationships 
> among the various proposals in the design space. Thanks for your patience.

I think the advantage for /not/ having a string interpolation prefix, is 
that then interpolation is “just another processor” e.g. a static method 
somewhere that takes a string template and returns a String. Another 
String::format, in a way. So that leads to a rather uniform design.

>
>
> And now that I have that better understanding, I think I lean toward 
> (a) abandoning string interpolation and (b) having a single, short, 
> _non-optional_ prefix for templates (“$” would be a plausible choice), 
> on the grounds that I think it makes code more readable if templates 
> are always distinguished up front from strings—and this is especially 
> helpful when the templates are rather long and any `\{` present might 
> be far from the beginning. It has a minimal number of cases to explain:
>
> “…”      string literal, must not contain \{…}, type String
> $”…”    template literal, may contain \{…}, type StringTemplate

Yep, I agreee this a very principled way to look at the problem.

>
> I think we have all made an honest effort to explain string templates 
> as a simple and clean superset of string literals, but now that we 
> have considered the typing and overloading issues, my opinion is that 
> it just isn’t possible without some amount of unwanted complication. 
> Strings and string templates are just different beasts, and we would 
> do well to maintain that distinction rather than trying to conflate 
> them. Yes, requiring a prefix on templates would impose a small 
> cost—perhaps we should regard it as a "syn-tax" rather than a “cover 
> charge”—on every template we write, but I judge that cost well worth 
> it for the readability it would buy.
>
> (By the way, I appreciate John’s suggestion of allowing a template to 
> begin with  “\{} , but this strikes me as kind of a hack rather than a 
> natural use of the \{…} syntax. A distinctive single-character prefix 
> would be better.)

I think there’s a place for {}. E.g. where {} shines IMHO, is to allow 
for /comments/ inside string templates:

|t""" hello this is \{ /* a comment here */ } a commented template """ |

But as a “template” prefix, it’s a bit of a lousy choice. For instance, 
one can argue that “1.0” is different from “1”. But there’s only one 
place where to look for that “.0”. Whereas, inside a text block, you can 
have many different places where the {} ends up. So, while this solves 
the problem for compiler writers, {} is not a good solution for us humans.

Maurizio

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240315/892cf0db/attachment-0001.htm>