> On Mar 9, 2024, at 6:52 PM, Brian Goetz <[email protected]> wrote: > > 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.
Yep, that is exactly what you would have to do: give preference to overloads that do not require the conversion. I don't doubt that this would require special finagling in the compiler’s overload resolution code, since it is not perfectly analogous to anything already in the language. > > 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. I’m all ears! >> 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. >> >
