Update on String Templates (JEP 459)

[Maurizio Cimadamore]

Hi
Is not all that rosy :-) Comments inline

On 15/03/2024 13:48, Victor Nazarov wrote:

> I think the above can be translated almost word for word to 
> StringTemplates world:
>
> * stringy-literal that doesn't have holes-with-values can be both 
> String and StringTemplate
> * stringy-literal that has holes-with-values can only be StringTemplate
> * m(String),m(StringTemplate) with stringy-literal that can be both 
> String and StringTemplate selects String-overload
> * t = s works as when t is StringTemplate and s is String

I assume you mean “s is a /constant/ String” here.

> * s = t is compile-time error
> * s = (String) t succeeds, when s is String and t is StringTemplate 
> (and does string concatenation)

Ok, here I note that you are defining cast conversion from 
StringTemplate to String as always successful (via interpolation).

> * t instanceof String succeeds on StringTemplate variable t as long as 
> t doesn't have any holes-with-values

This is inconsistent. You now have cases where “t instanceof String” 
returns false, but where (String)t succeds.

> * s instanceof StringTemplate succeeds when s is String

Again, probably you mean “constant String” here.

> * additionally stringy-literal can use "t" or "T" *suffix* to denote 
> that it is really a template, this can be used to tweak 
> overload-selection and to certify, that some processing of values is 
> expected

Overall, while I agree this is not completely terrible, we are signing 
up for a lot of work here. There’s new conversion, relationship with 
pattern matching and instanceof to figure out, possible issues with 
overload resolution and inference. For instance, yesterday I mentioned 
this example:

|List<StringTemplate> ls = List.of("Hello"); |

Which won’t work. One way to look at it, is that it’s as broken as:

|List<Long> ls = List.of(1); |

But another way to look at it is that we’re adding more complexity to a 
part of the language that already is shaky. To me that feels like a big 
risk, especially given that the "payoff" is to leave an extra “t” out at 
the beginning of the template. In orther words, we should be careful 
about right-sizing complexity.

Also, regarding:

> 2) avoiding proliferation of String-literal sublanguages as advocated 
> by Brian Goetz

I don’t read that in the same way as you do. I think what Brian meant is 
that anything inside quotes should be uniform. We would not like to have 
different kinds of rules for escaping etc. depending on what kind of 
literal you use. In that sense, sticking a “t” in front is no different 
from using “”” to denote that what’s coming is a text block.

Maurizio

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20240315/765bc0c7/attachment.htm>