Update on String Templates (JEP 459)

[Victor Nazarov]

Below are some more comments, just to close the loop, but what I really
wanted it to highlight once more, that we can treat all Strings as
StringTemplates, not "constant" Strings-literals, but really all Strings.
Each string is a degenerate StringTemplate without holes, the same way as
each integer-number is a degenerate double-number without a non-integer
part.

On Fri, Mar 15, 2024 at 3:54 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> 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.
>

No, what I mean is that we can always assign a string to a string template.

StringTemplate t;
String s = "hello";
t = s; // no error, implicit conversion

the same way as we can do

long x;
int y = 5;
x = y;

but we can not do this in backward direction:

> * s = t is compile-time error
>
> > Incompatible types: possible lossy conversion from StringTemplate to
String

the same way as

int x;
long y = 5;
x = y;

results in

> Incompatible types: possible lossy conversion from long to int

> * s = (String) t succeeds, when s is String and t is StringTemplate (and
> does string concatenation)
>
>
Yes, cast is an interpolation, so

int x = 5;
int y = 10;
StringTemplate t = "\{x} + \{y}";
String s = (String) t;
assert s.equals("4 + 10");

Cast is some operation that causes loss of information and is generally
considered unsafe, this is similar to:

long x = 0x10_7F_FF_FF_FFL;
int y = (int) x;
assert y == 0x7F_FF_FF_FFL;
>
> 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.
>

I'm not sure this is inconsistent, I think this is exactly what is proposed
in JEP 455. I think the confusion here is the definition of "succeeds", I
think what you mean is throwing ClassCastException, but in JEP 455
"succeeds" means without the loss of information. One of the examples is

int i = 42;
i instanceof byte;        // true (exact)

int i = 1000;
i instanceof byte;        // false (not exact)

So this can be the same with StringTemplates and Strings

StringTemplate t = "hello";
t instanceof String;        // true (exact)

int i = 1000;
StringTemplate t = "i = \{i}"
i instanceof String;        // false (not exact)

* s instanceof StringTemplate succeeds when s is String
>
> Again, probably you mean “constant String” here.
>

I mean any String succeeds here, the same way as

b instanceof int;         // true (unconditionally exact)


is always true, because there is never loss of any information.

* 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.
>
First of all, I think I'm in no position to talk about
implementation-complexity, but even from the specification complexity, I
think I mostly agree that the cost of leaving out some extra "t" or "$"
seems too big.
I think I was always against StringTemplates that look exactly like
Strings. As a matter of fact I was one of the initial set of people who
proposed a RAW-processor to replace implicit conversion from
StringTemplates to Strings.

What I wanted to state here is that there is still a way to make the
implicit-conversion story mostly consistent and there is already an
inspiration in the language to rely upon.
I think the thing that mostly defeats the proposed scheme to me, is that
the cast operation for reference types was always about subtyping, but here
we create a special case for two reference-types: String and StringTemplate
that are not properly subtypes of one-another, but have
conversion-relationship.

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.
>
I think there is a specter of things that a language designer can do to
underline or undermine similarities, surely having same delimiters
communicate much better, that rules inside are the same. John Roses
proposal about some special thing *inside* the quotes also communicates
this idea better, then some prefix/suffix right before/after the quotes.

--
Victor Nazarov

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20240319/1bfa96c4/attachment-0001.htm>