This is a very important example to consider. I observe, however, that there
are at least two possible ways to avoid the unpleasant surprise:
(1) Don't have string interpolation literals, because accidentally using a
string interpolation literal instead of a string template literals can result
in invoking the wrong overload of a method.
(2) Don’t overload methods so as to accept either a string or a string template.
If we were to take approach (2), then:
(a) We would keep `println` as is, and not allow it to accept a template, but
that’s okay—if you thought you wanted a template, what you really want is plan
old string interpolation, and the type checking will make sure you don't use
the wrong one.
(b) A SQL processor would accept a template but not a string—if you thought you
wanted string interpolation, what you really want is a template, and the type
checking will make sure you don't use the wrong one.
(c) I think `format` is a special case that we tend to get hung up on, and I
think that, in this particular branch of the design space we are exploring,
perhaps a name other than `String.format` should be chosen for the method that
does string formatting on templates. Possible names are `StringTemplate.format`
and `String.format$`, but I will leave further bikeshedding on this to others.
I do recognize that this move will not enable the type system per se to
absolutely prevent programmers from writing
String.format("Hello, my name is %s{name}"); // can you spot the bug?
but, as Clement has observed, such cases will probably provoke a warning about
a mismatch between the number of arguments and the number of %-specifiers that
require parameters, so maybe overloading would be okay anyway for
`String.format`.
Anyway, my point is that whether to overload a method to accept either a string
or a string template can be evaluated on a case-by-case basis according to a
small number of principles that I think we could enumerate and explain pretty
easily.
—Guy
On Mar 14, 2024, at 1:40 PM, Maurizio Cimadamore
<[email protected]> wrote:
Not to pour too much cold water on the idea of having string interpolation
literal, but I’d like to mention a few points here.
First, it was a deliberate design goal of the string template feature to make
interpolation an explicit act. Note that, if we had the syntax you describe, we
actually achieve the opposite effect: string interpolation is now the default,
and implicit, and actually cheaper (to type) than the safer template
alternative. This is a bit of a red herring, I think.
The second problem is that interpolation literals can sometimes be deceiving.
Consider this example:
String.format("Hello, my name is %s{name}"); // can you spot the bug?
Where String::format has a new overload which accepts a StringTemplate.
Basically, since here we forgot the leading “$” (or whatever char that is), the
whole thing is just a big interpolation. Semantically equivalent to:
String.format("Hello, my name is %s" + name); // whoops!
This will fail, as String::format will be waiting for an argument (a string),
but none is provided. So:
| Exception java.util.MissingFormatArgumentException: Format specifier '%s'
| at Formatter.format (Formatter.java:2672)
| at Formatter.format (Formatter.java:2609)
| at String.format (String.java:2897)
| at (#2:1)
This is a very odd (and new!) failure mode, that I’m sure is gonna surprise
developers.
Maurizio
On 14/03/2024 15:08, Guy Steele wrote:
Second thoughts about how to explain a string interpolation literal:
On Mar 13, 2024, at 2:02 PM, Guy Steele
<[email protected]><mailto:[email protected]> wrote:
. . .
—————————
String is not a subtype of StringTemplate; they are disjoint types.
$”foo” is a (trivial) string template literal
“foo” is a string literal
$”Hello, \{x}” is a (nontrivial) string template literal
“Hello, \{x}” is a shorthand (expanded by the compiler) for
`String.of($“Hello, \{x}”)`
—————————
Given that the intent is that String.of (or whatever we want to call
it—possibly the `interpolation` instance method of class `StringTemplate`
rather than a static method `String.of`) should just do standard string
concatenation, we might be better off just saying that a string interpolation
literal is expanded by the compiler into uses of “+”; for example,
“Hello, \{x}.”
(I have added a period to the example to make the point clearer) is expanded
into
“Hello, “ + x + “.”
and in general
“c0\{e1}c1\{e2}c2…\{en}cn”
(where each ck is a possibly empty sequence of string characters and each ek is
an expression) is expanded into
“c0” + (e1) + “c1” + (e2) + “c2” + … + (en) + “cn”
The point is that, with this definition, “c0\{e1}c1\{e2}c2…\{en}cn” is a
constant expression iff every ek is a constant expression. This is handy for
interpolating constant variables into a string that is itself intended to be
constant.
—Guy
