Update on String Templates (JEP 459)

[Archie Cobbs]

On Tue, Mar 12, 2024 at 12:08 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Have I covered the concerns raised so far?
>

Thanks for the helpful discussion check-point.

This thread has touched on a lot of different bits so for a moment I want
to focus on one narrow question. Forget for a moment all the stuff about
method resolution, varargs, and whether String <: StringTemplate.

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"?

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/d6ccf6bf/attachment.htm>