Maurizio did prototype almost exactly this: treat compile-time constant string expressions as poly expressions whose standalone type is String but which could be treated as ST as well. I’ll let him recap the details, but I think the upshot was that we had overload selection problems with m(String) vs m(StringTemplate), as both were applicable, unless we wanted to treat this as akin to a boxing conversion where we preferred “unboxed” overloads as we do with loose vs strict method invocation contexts.
There were other things we tried too for the special case of string literals as degenerate templates — I’ll let Maurizio give the details, because I’m sure I will have forgotten one or two. > On Mar 9, 2024, at 12:45 PM, Guy Steele <[email protected]> wrote: > > > Sent from my iPhone > >> On Mar 9, 2024, at 12:03 PM, Brian Goetz <[email protected]> wrote: >> . . . >> At root, this is a workaround for “a string *literal* with no holes might >> want to be a template.” I don’t think it makes sense to interpret *all* >> strings as templates. And this led to some annoying overload selection / >> inference decisions (tinkering with the super types of String ripples >> throughout the JDK.). > > Right, we don’t want to interpret all strings as templates, and we don’t want > to have a conversion that lets any String expression to be converted to a > template. > > But what about a more targeted conversion? > > Recall that assignment conversion has a special case that allows a narrowing > primitive conversion under certain circumstances where the right-hand side is > a constant expression, thus allowing assignment of, for example, the constant > literal 1 (nominally of type int) to a variable of type byte, short, or char. > > Have you considered allowing conversion of _constant_ expressions of type > String to templates in assignment contexts and invocation contexts? > (Presumably this could be implemented by having the compiler automatically > wrap the constant expression within an invocation of something like > StringTemplate.of(…).) This would of course kick in for a method invocation > only if there is no applicable overloading that does not need the conversion. > > As a rule I don’t like enlarging the can of worms known as “special-case > conversions”, but I think this would have sufficient utility that it would be > worth doing, especially given the precedent that the compiler already knows a > great deal of special information about class Java.lang.String. >
