Update on String Templates (JEP 459)

[Maurizio Cimadamore]

On 11/03/2024 13:01, Remi Forax wrote:
> It's not a real boxing conversion, because it's a one way conversion, 
> i.e. there is a boxing conversion between StringTemplate to String but 
> no boxing conversion from String to StringTemplate. We can add it, but 
> i do not think it's necessary given that with a String s, it can 
> always be converted to a StringTemplate using t"\{s}".

This approach goes against the goal of making template -> string 
conversion explicit.

While turning a string into a template is totally safe (after all, a 
string is a degenerate case of a template with no values), the reverse 
is not true: there are many ways to go from a template to a string and 
either the user (at the use site) or the library (at the decl site) will 
have to "say what they mean". Now, you might disagree with this, but, as 
stated by Brian, this change is not about relaxing the design goals in 
JEP 465.

This is why, in my email, I'm specifically only speaking about the 
String -> StringTemplate direction.

> Apart from the fact that adding overloads in a lot of existing 
> projects looks like a sisiphus task, doing the conversion at use site 
> also as the advantage of allowing the compiler generates an 
> invokedynamic at use site so the boxing from a StringTemplate to a 
> String will be as fast as the string concatenation using '+' (see 
> Duncan email on amber-dev).
We can make things fast in other ways. For instance, given that string 
interpolation will be rather common, we might cache the string 
interpolation MH in the literal directly (after all, such literal is 
associated with an indy callsite). Other, more dynamic, approaches are 
possible too. I believe Jim might provide more details on how exactly 
this can be achieved, but I think that for now it would be better not to 
let the performance considerations drive the discussion.

Maurizio