<div dir="ltr"><div>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.</div><div>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.</div><div></div><div><br></div><div>On Fri, Mar 15, 2024 at 3:54 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<div>
<p style="margin:0px 0px 1.2em">Hi<br>
Is not all that rosy :-) Comments inline</p>
<p style="margin:0px 0px 1.2em">On 15/03/2024 13:48,
Victor Nazarov wrote:</p>
<p style="margin:0px 0px 1.2em"></p>
<div>
<p></p>
<blockquote type="cite">
<div>I think the above can be translated almost word for word
to StringTemplates world:</div>
<div><br>
</div>
<div>
<div>* stringy-literal that doesn't have holes-with-values
can be both String and StringTemplate<br>
</div>
<div>* stringy-literal that has holes-with-values can only
be StringTemplate</div>
<div>* m(String),m(StringTemplate) with stringy-literal that
can be both String and StringTemplate selects
String-overload</div>
* t = s works as when t is StringTemplate and s is String<br>
</div>
</blockquote>
<p></p>
</div>
<p style="margin:0px 0px 1.2em"></p>
<p style="margin:0px 0px 1.2em">I assume you mean “s
is a <i>constant</i> String” here.</p></div></div></blockquote><div><br></div><div>No, what I mean is that we can always assign a string to a string template.</div><div><br></div><div>StringTemplate t;</div><div>String s = "hello";</div><div>t = s; // no error, implicit conversion</div><div><br></div><div>the same way as we can do</div><div><br></div><div>long x;</div><div>int y = 5;</div><div>x = y;</div><div><br></div><div>but we can not do this in backward direction:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
<p style="margin:0px 0px 1.2em"></p>
<div>
<p></p>
<blockquote type="cite">
<div>
<div>
<div>* s = t is compile-time error<br></div></div></div></blockquote></div></div></div></blockquote><div>> Incompatible types: possible lossy conversion from StringTemplate to String</div><div><br></div><div>the same way as</div><div><br></div><div>int x;<br>long y = 5;<br>x = y;</div><div><br></div><div>results in</div><div><br></div><div>> Incompatible types: possible lossy conversion from long to int</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><blockquote type="cite"><div><div><div>
</div>
<div>
<div>
<div>* s = (String) t succeeds, when s is String and t
is StringTemplate (and does string concatenation)<br></div></div></div></div></div></blockquote></div></div></div></blockquote><div><br></div><div>Yes, cast is an interpolation, so</div><div><br></div><div>int x = 5;</div><div>int y = 10;</div><div>StringTemplate t = "\{x} + \{y}";</div><div>String s = (String) t;</div><div>assert s.equals("4 + 10");</div><div><br></div><div>Cast is some operation that causes loss of information and is generally considered unsafe, this is similar to:</div><div><br></div>long x = 0x10_7F_FF_FF_FFL;<br>int y = (int) x;<br>assert y == 0x7F_FF_FF_FFL;<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><blockquote type="cite"><div><div><div><div><div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p></p>
</div>
<p style="margin:0px 0px 1.2em"></p>
<p style="margin:0px 0px 1.2em">Ok, here I note that
you are defining cast conversion from StringTemplate to String
as always successful (via interpolation).</p>
<p style="margin:0px 0px 1.2em"></p>
<div>
<p></p>
<blockquote type="cite">
<div>
<div>
<div>
<div>* t instanceof String succeeds on StringTemplate
variable t as long as t doesn't have any
holes-with-values<br>
</div>
</div>
</div>
</div>
</blockquote>
<p></p>
</div>
<p style="margin:0px 0px 1.2em"></p>
<p style="margin:0px 0px 1.2em">This is inconsistent.
You now have cases where “t instanceof String” returns false,
but where (String)t succeds.</p></div></div></blockquote><div><br></div><div>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</div><div><br></div><div><pre><code>int i = 42;
i instanceof byte; // true (exact)
int i = 1000;
i instanceof byte; // false (not exact)
</code><code><br></code></pre><pre><code>So this can be the same with StringTemplates and Strings<br><br></code><code>StringTemplate t = "hello";
t instanceof String; // true (exact)
int i = 1000;<br>StringTemplate t = "i = \{i}"
i instanceof </code><code>String</code><code>; // false (not exact)
</code><code><br></code><code></code></pre></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
<p style="margin:0px 0px 1.2em"></p>
<div>
<p></p>
<blockquote type="cite">
<div>
<div>
<div>
<div>* s instanceof StringTemplate succeeds when s is
String<br>
</div>
</div>
</div>
</div>
</blockquote>
<p></p>
</div>
<p style="margin:0px 0px 1.2em"></p>
<p style="margin:0px 0px 1.2em">Again, probably you
mean “constant String” here.</p></div></div></blockquote><div><br></div><div>I mean any String succeeds here, the same way as</div><div><br></div><div><pre><code>b instanceof int; // true (unconditionally exact)</code></pre></div><div> </div><div>is always true, because there is never loss of any information.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
<p style="margin:0px 0px 1.2em"></p>
<div>
<p></p>
<blockquote type="cite">
<div>
<div>
<div>
<div>* 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</div>
</div>
</div>
</div>
</blockquote>
<p></p>
</div>
<p style="margin:0px 0px 1.2em"></p>
<p style="margin:0px 0px 1.2em">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:</p>
<pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;background-color:rgb(248,248,248);white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block">List<StringTemplate> ls = List.of("Hello");
</code></pre>
<p style="margin:0px 0px 1.2em">Which won’t work. One
way to look at it, is that it’s as broken as:</p>
<pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;background-color:rgb(248,248,248);white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block"> List<Long> ls = List.of(1);
</code></pre>
<p style="margin:0px 0px 1.2em">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.<br></p></div></div></blockquote><div>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.<br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><p style="margin:0px 0px 1.2em">
</p>
<p style="margin:0px 0px 1.2em">Also, regarding:</p>
<p style="margin:0px 0px 1.2em"></p>
<div>
<p></p>
<blockquote type="cite">
<div>2) avoiding proliferation of String-literal sublanguages
as advocated by Brian Goetz</div>
</blockquote>
<p></p>
</div>
<p style="margin:0px 0px 1.2em"></p>
<p style="margin:0px 0px 1.2em">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.</p></div></div></blockquote><div>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.</div><div><br></div><div>--</div><div>Victor Nazarov<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div title="MDH:PHA+SGk8YnI+SXMgbm90IGFsbCB0aGF0IHJvc3kgOi0pIENvbW1lbnRzIGlubGluZTxicj48L3A+
PGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxNS8wMy8yMDI0IDEzOjQ4LCBWaWN0b3Ig
TmF6YXJvdiB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlk
OkNBRk9rV1piRjVtLUxCNnpDcVlyRVl1Z2QzR055b3VWVFhDcExDcW45dXd4NXZRaExhZ0BtYWls
LmdtYWlsLmNvbSI+PGRpdj5JIHRoaW5rIHRoZSBhYm92ZSBjYW4gYmUgdHJhbnNsYXRlZCBhbG1v
c3Qgd29yZCBmb3Igd29yZCB0byBTdHJpbmdUZW1wbGF0ZXMgd29ybGQ6PC9kaXY+PGRpdj48YnI+
PC9kaXY+PGRpdj48ZGl2Piogc3RyaW5neS1saXRlcmFsIHRoYXQgZG9lc24ndCBoYXZlIGhvbGVz
LXdpdGgtdmFsdWVzIGNhbiBiZSBib3RoIFN0cmluZyBhbmQgU3RyaW5nVGVtcGxhdGU8YnI+PC9k
aXY+PGRpdj4qJm5ic3A7c3RyaW5neS1saXRlcmFsIHRoYXQgaGFzIGhvbGVzLXdpdGgtdmFsdWVz
IGNhbiBvbmx5IGJlIFN0cmluZ1RlbXBsYXRlPC9kaXY+PGRpdj4qIG0oU3RyaW5nKSxtKFN0cmlu
Z1RlbXBsYXRlKSB3aXRoJm5ic3A7c3RyaW5neS1saXRlcmFsIHRoYXQgY2FuIGJlIGJvdGggU3Ry
aW5nIGFuZCBTdHJpbmdUZW1wbGF0ZSBzZWxlY3RzIFN0cmluZy1vdmVybG9hZDwvZGl2PiogdCA9
IHMgd29ya3MgYXMgd2hlbiB0IGlzIFN0cmluZ1RlbXBsYXRlIGFuZCBzIGlzIFN0cmluZzxicj48
L2Rpdj48L2Jsb2NrcXVvdGU+SSBhc3N1bWUgeW91IG1lYW4gInMgaXMgYSBfY29uc3RhbnRfIFN0
cmluZyIgaGVyZS48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOkNBRk9rV1pi
RjVtLUxCNnpDcVlyRVl1Z2QzR055b3VWVFhDcExDcW45dXd4NXZRaExhZ0BtYWlsLmdtYWlsLmNv
bSI+PGRpdj48ZGl2PjxkaXY+KiBzID0gdCBpcyBjb21waWxlLXRpbWUgZXJyb3I8YnI+PC9kaXY+
PGRpdj48ZGl2PjxkaXY+KiBzID0gKFN0cmluZykgdCBzdWNjZWVkcywgd2hlbiBzIGlzIFN0cmlu
ZyBhbmQgdCBpcyBTdHJpbmdUZW1wbGF0ZSAoYW5kIGRvZXMgc3RyaW5nIGNvbmNhdGVuYXRpb24p
PGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT5PaywgaGVyZSBJ
IG5vdGUgdGhhdCB5b3UgYXJlIGRlZmluaW5nIGNhc3QgY29udmVyc2lvbiBmcm9tIFN0cmluZ1Rl
bXBsYXRlIHRvIFN0cmluZyBhcyBhbHdheXMgc3VjY2Vzc2Z1bCAodmlhIGludGVycG9sYXRpb24p
Ljxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6Q0FGT2tXWmJGNW0tTEI2ekNx
WXJFWXVnZDNHTnlvdVZUWENwTENxbjl1d3g1dlFoTGFnQG1haWwuZ21haWwuY29tIj48ZGl2Pjxk
aXY+PGRpdj48ZGl2PiogdCBpbnN0YW5jZW9mIFN0cmluZyBzdWNjZWVkcyBvbiBTdHJpbmdUZW1w
bGF0ZSB2YXJpYWJsZSB0IGFzIGxvbmcgYXMgdCBkb2Vzbid0IGhhdmUgYW55IGhvbGVzLXdpdGgt
dmFsdWVzPGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT5UaGlzIGlzIGlu
Y29uc2lzdGVudC4gWW91IG5vdyBoYXZlIGNhc2VzIHdoZXJlICJ0IGluc3RhbmNlb2YgU3RyaW5n
IiByZXR1cm5zIGZhbHNlLCBidXQgd2hlcmUgKFN0cmluZyl0IHN1Y2NlZHMuPGJyPjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpDQUZPa1daYkY1bS1MQjZ6Q3FZckVZdWdkM0dOeW91
VlRYQ3BMQ3FuOXV3eDV2UWhMYWdAbWFpbC5nbWFpbC5jb20iPjxkaXY+PGRpdj48ZGl2PjxkaXY+
KiBzIGluc3RhbmNlb2YgU3RyaW5nVGVtcGxhdGUgc3VjY2VlZHMgd2hlbiBzIGlzIFN0cmluZzxi
cj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+QWdhaW4sIHByb2JhYmx5IHlv
dSBtZWFuICJjb25zdGFudCBTdHJpbmciIGhlcmUuPGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
IGNpdGU9Im1pZDpDQUZPa1daYkY1bS1MQjZ6Q3FZckVZdWdkM0dOeW91VlRYQ3BMQ3FuOXV3eDV2
UWhMYWdAbWFpbC5nbWFpbC5jb20iPjxkaXY+PGRpdj48ZGl2PjxkaXY+KgogYWRkaXRpb25hbGx5
Jm5ic3A7c3RyaW5neS1saXRlcmFsIGNhbiB1c2UgInQiIG9yICJUIiAqc3VmZml4KiB0byBkZW5v
dGUgdGhhdCAKaXQgaXMgcmVhbGx5IGEgdGVtcGxhdGUsIHRoaXMgY2FuIGJlIHVzZWQgdG8gdHdl
YWsgb3ZlcmxvYWQtc2VsZWN0aW9uIGFuZCB0byBjZXJ0aWZ5LCB0aGF0IHNvbWUgcHJvY2Vzc2lu
ZyBvZiB2YWx1ZXMgaXMgZXhwZWN0ZWQ8L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVv
dGU+PHA+PGJyPjwvcD48cD5PdmVyYWxsLCB3aGlsZSBJIGFncmVlIHRoaXMgaXMgbm90IGNvbXBs
ZXRlbHkgdGVycmlibGUsIHdlIGFyZSBzaWduaW5nIHVwIGZvciBhIGxvdCBvZiB3b3JrIGhlcmUu
IFRoZXJlJ3MgbmV3IGNvbnZlcnNpb24sIHJlbGF0aW9uc2hpcCB3aXRoIHBhdHRlcm4gbWF0Y2hp
bmcgYW5kIGluc3RhbmNlb2YgdG8gZmlndXJlIG91dCwgcG9zc2libGUgaXNzdWVzIHdpdGggb3Zl
cmxvYWQgcmVzb2x1dGlvbiBhbmQgaW5mZXJlbmNlLiBGb3IgaW5zdGFuY2UsIHllc3RlcmRheSBJ
IG1lbnRpb25lZCB0aGlzIGV4YW1wbGU6PC9wPjxwPmBgYDxicj5MaXN0Jmx0O1N0cmluZ1RlbXBs
YXRlJmd0OyBscyA9IExpc3Qub2YoIkhlbGxvIik7PGJyPmBgYDwvcD48cD5XaGljaCB3b24ndCB3
b3JrLiBPbmUgd2F5IHRvIGxvb2sgYXQgaXQsIGlzIHRoYXQgaXQncyBhcyBicm9rZW4gYXM6PC9w
PjxwPmBgYDxicj4KTGlzdCZsdDtMb25nJmd0OyBscyA9IExpc3Qub2YoMSk7PGJyPgpgYGA8L3A+
PHA+QnV0IGFub3RoZXIgd2F5IHRvIGxvb2sgYXQgaXQgaXMgdGhhdCB3ZSdyZSBhZGRpbmcgbW9y
ZSBjb21wbGV4aXR5IHRvIGEgcGFydCBvZiB0aGUgbGFuZ3VhZ2UgdGhhdCBhbHJlYWR5IGlzIHNo
YWt5LiBUbyBtZSB0aGF0IGZlZWxzIGxpa2UgYSBiaWcgcmlzaywgZXNwZWNpYWxseSBnaXZlbiB0
aGF0IHRoZSBwYXlvZmYgaXMgdG8gbGVhdmUgYW4gZXh0cmEgInQiIG91dCBhdCB0aGUgYmVnaW5u
aW5nIG9mIHRoZSB0ZW1wbGF0ZS48L3A+PHA+QWxzbywgcmVnYXJkaW5nOjxicj48YnI+PGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4yKSBhdm9pZGluZyBwcm9saWZlcmF0aW9uIG9mIFN0cmlu
Zy1saXRlcmFsIHN1Ymxhbmd1YWdlcyBhcyBhZHZvY2F0ZWQgYnkgQnJpYW4gR29ldHo8L2Rpdj48
L2Jsb2NrcXVvdGU+PGJyPkkgZG9uJ3QgcmVhZCB0aGF0IGluIHRoZSBzYW1lIHdheSBhcyB5b3Ug
ZG8uIEkgdGhpbmsgd2hhdCBCcmlhbiBtZWFudCBpcyB0aGF0IGFueXRoaW5nIGluc2lkZSBxdW90
ZXMgc2hvdWxkIGJlIHVuaWZvcm0uIFdlIHdvdWxkIG5vdCBsaWtlIHRvIGhhdmUgZGlmZmVyZW50
IGtpbmRzIG9mIHJ1bGVzIGZvciBlc2NhcGluZyBldGMuIGRlcGVuZGluZyBvbiB3aGF0IGtpbmQg
b2YgbGl0ZXJhbCB5b3UgdXNlLiBJbiB0aGF0IHNlbnNlLCBzdGlja2luZyBhICJ0IiBpbiBmcm9u
dCBpcyBubyBkaWZmZXJlbnQgZnJvbSB1c2luZyAiIiIgdG8gZGVub3RlIHRoYXQgd2hhdCdzIGNv
bWluZyBpcyBhIHRleHQgYmxvY2suPC9wPjxwPk1hdXJpemlvPGJyPjwvcD4KPHA+PGJyPjwvcD48
cD48L3A+" style="height:0px;width:0px;max-height:0px;max-width:0px;overflow:hidden;font-size:0em;padding:0px;margin:0px"></div>
</div>
</div>
</blockquote></div></div>