Update on String Templates (JEP 459)

[John Rose]

On 9 Mar 2024, at 3:48, Tagir Valeev wrote:

> The idea is interesting. There's a thing that disturbs me though.
> Currently, proc."string" and proc."string \{template}" are uniformly
> processed, and the processor may not care much about whether it's a string
> or a template: both can be processed uniformly. After this change, removing
> the last embedded expression from the template (e.g., after inlining a
> constant) will implicitly change the type of the literal from
> StringTemplate to String. This may either cause a compilation error, or
> silently bind to another overload which may or may not behave like a
> template overload with a single-fragment-template. For API authors, this
> means that every method accepting StringTemplate should have a counterpart
> accepting String. The logic inside both methods would likely be very
> similar, so probably both will eventually call a third private method. For
> API user, it could be unclear how to call a method accepting StringTemplate
> if I have simple string in hands but there's no String method (or it does
> slightly different thing due to poor API design). Should I use some ugly
> construct like "This is a string but the API wants a template, so I append
> an empty embedded expression\{""}"?

This is a huge thread that I hesitate to dive into, but here’s me putting in one toe:  Why do we care so much about no-arg string templates?  It’s a small corner case!  The workarounds (for the no-arg case) are totally straightforward even if the string template literals (as a syntax) are required to have at least one argument.

Can we have a plausible use case, please, for why a ST with no arguments would be important, so important that we are motived to invent a sigil syntax or special type system rules, to avoid requiring the user to invoke a static factory?

Also, Tagir’s workaround of adding a fake argument looks like it would work just fine, of course depending on which processor was eventually used.

And in that vein let me add one new (very bike-sheddy) suggestion before I beat a hasty retreat:  Instead of in (1) a sigil before the quote like Guy’s $"hello", put it (1b) after the quote, and in the ST case only.  The ST syntax could explicitly allow that a no-arg string template would be spelled with a leading sequence "\{}... which looks like the coder started writing a ST argument, but in fact dropped it.  So "hello" is a 5-char string, in any context.  And "\{}hello" is a 5-char no-arg string template, in any context.  That’s Tagir’s workaround, elevated a bit into a new corner case of (existing) syntax.

But even that teeny bit of syntax strikes me as overkill, because I don’t see the importance of the use cases (no-arg STs) it helps.  Just call ST.of("hello") and call it a day.

In any case, it seems fine to let the IDE take the lead with no-arg STs, helping the user decide when and how to disambiguate strings from no-arg STs.  Putting in syntax or type system help for this is surely more expensive than punting to the IDE, unless there is going to be heavy use of no-arg STs for some use cases I am not seeing.