Update on String Templates (JEP 459)

[Brian Goetz]

On 3/13/2024 10:48 AM, Archie Cobbs wrote:
>
> I was intrigued by this comment (Maurizio):
>
> > Another, simpler, option we considered was to use some kind of 
> prefix to mark a string template literal (e.g. make that explicit, 
> instead of resorting to language wizardry). That works, but has the 
> disadvantage of breaking the spell that there is only “one string 
> literal”, which is something we have worked quite hard to achieve.
>
> What exactly is the advantage, in terms of the mental model of the 
> programmer, of having "one string literal"?

When we started doing text blocks, we did a survey of string 
literal-like features in other languages, and were a little concerned 
that a lot of languages had a proliferation of different kinds of 
strings with different rules.   (An example of "different rules for 
different kinds of strings" would be that $ is a regular character in a 
string literal, but an escape character in an interpolated string.)

Before we figured out the design center of text blocks (think 
"two-dimensional string literals"), there were a number of envisioned 
extension directions for string literals -- multi-line, raw, embedded 
expressions, etc.  And because these extension directions are 
orthogonal, there could easily be 2^n kinds of string literal.  We 
didn't want to put users in a position of having to choose between e.g., 
"raw" and "multi-line", nor did we want to risk there being interactions 
between the rules for these different sub-kinds.

One technique we use to tie together these various forms is by having a 
common sub-language within the quotes; each of the forms uses the same 
set of escape sequences (though this set is extended with 
context-specific options, such as \{ for templates.)  Another is the 
delimiters; they are all "double-quote flavored", again to provide a 
sense that these are all projections of the same core literal feature.  
The more we wander from this center, the more we risk ending up with 
locally-sane but globally-inconsistent sub-features.



> Maybe I'm just not seeing it.
>
> I can understand the advantage of having String <: StringTemplate - 
> that gives me more flexibility when passing around objects - great! 
> But do I need that same flexibility with /literals/?
>
> Consider how we handle float vs. double literals. They overlap for 
> 32-bit values, which is very convenient, but you can also "force" a 
> narrower interpretation by adding an "f" suffix. That seems like 
> pretty much the best of both worlds to me.
>
> So is this an analogous situation? Then we'd allow a StringTemplate 
> literal to have an /optional/ "$" prefix:
>
> obj.takingString("abcd");             // ok - string
> obj.takingTemplate("abcd"); // ok - template
> obj.takingStringOrTemplate($"abcd"); // ok - template
> obj.takingStringOrTemplate("abcd"); // ok - string or template 
> (personally I don't care)
> obj.takingString($"abcd"); // fail
> obj.takingTemplate($"abcd"); // ok - template
> obj.takingString("x = \{var}"); // fail
> obj.takingTemplate("x = \{var}"); // ok - template
>
> Thanks,
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20240313/22db4246/attachment.htm>