Given that few APIs will take StringTemplate on Day 1, I've been
wondering how people will approach making string templates interoperate
with APIs that only take String. They'll try the converts-to-String
functionality of + -- "" + <<string template>> -- and find it's a dead
end.
BTW, it's always been true that there's no empty template literal, but
with the removal of template processors there will be more "standalone"
StringTemplate variables, and this will be a common error:
StringTemplate st = ""; // Error, can't assign String to StringTemplate
I also wondered if it could ever mean anything to compose two string
templates with +. It feels similar to embedding a string template in a
template literal. If the two templates being composed are in the same
"language" then perhaps the Java language could help combine them.
Alex
On 3/11/2024 1:47 PM, Jim Laskey wrote:
String plus isn’t needed. Just as templates remove the need for string plus,
the combining of string templates and strings can be done with nested embedded
expressions.
📱
On Mar 11, 2024, at 5:25 PM, Alex Buckley <[email protected]> wrote:
On 3/11/2024 10:36 AM, Brian Goetz wrote:
Overall, though, I am not so enthused about creating yet another new lexical
mechanism for having different kinds of stringy things.
All strings -- not just string literals, and not just constant expressions of
type String -- can be composed with +. Is there an equivalent composition
operator for string templates? (That is, all values of type StringTemplate, not
just template literals.)
I ask because the more lexical similarity between a template literal and a
string literal, the more I think people will try to use + with two template
literals, or with one template literal and one string literal. AIUI the result
will be a surprise:
String s = "Hello" + "\{x}";
// Second operand to + undergoes string conversion a.k.a. toString()
print(s); // Hello0x12345678
Alex
