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
