Oracle managed to create one of the least ergonomic string interpolation syntaxes of any language I've ever seen. Using backslashes is truly a terrible move
C# $"{x} plus {y} equals {x + y}"
Visual Basic $"{x} plus {y} equals {x + y}"
Python f"{x} plus {y} equals {x + y}"
Scala s"$x plus $y equals ${x + y}"
Groovy "$x plus $y equals ${x + y}"
Kotlin "$x plus $y equals ${x + y}"
JavaScript `${x} plus ${y} equals ${x + y}`
Ruby "#{x} plus #{y} equals #{x + y}"
Swift "\(x) plus \(y) equals \(x + y)"
Is any of those actually better? You have a non-existing better suggestion that works in the same cases they outline in the JEP?
I think the following is the main part to keep in mind:
> For Java, we would like to have a string composition feature that achieves the clarity of interpolation but achieves a safer result out-of-the-box, perhaps trading off a small amount of convenience to gain a large amount of safety.
I agree that $ is more common and causes less visual friction, but what I like about \{} is that on my keyboard they are three keys adjacent to each other.
I’d say valuing shorter syntax is better which is subjective, but then measuring it is objective. Requiring 3 chars per variable is silly when many languages only require 1
It's fine to break backwards compatibility when introducing an entirely new feature across a major version, actually. What's even the point of a major version bump?
Not everyone uses semver, although in any case Java "major" versions are actually a continuation of what was called the 1.x line -- they gave up on writing out the "1." a couple of decades ago. They're semver minor release, not semver major.
Plus, prepending the string with `STR.` changes the syntax entirely. Those strings are still invalid if you don't prepend `STR.` (which is another thing I hate, but not quite as much).
In C#, the string `"""Hello world"` is invalid, but `@"""Hello world"` is, because double quotes are valid with verbatim string literals.
There was a nice long deprecation period between those versions, where everyone using it got a warning. And then, when it was finally removed, everyone using it got an error, and they were forced to change their code. By contrast, a string literal could silently change meaning if it used syntax that was previously valid in strings. This is the exact same reason JS chose to require backticks to delimit interpolable strings - because otherwise existing string literals could silently change meaning.
I hadn't caught that this was required, but then it'd lock them out of removing that requirement. Plus it'd complicate the parser, to have there be two different kinds of string literals syntactically.
May I introduce to Swift? They even decided on that without any backwards compatibility limitations. It really is not bad, does it really matter if it’s a $ or a \ ?
using backslashes for anything other than escaping a characters (e.g: \" or \n) makes it a nightmare to try to coerce the compiler into understanding what you're trying to do if you combine escape characters and syntax in the same string
Try, for example, generating a regular expression which features backslashes in it. You will get an unreadable mess and probably have to play with it for a while before java will even compile it
The backslash is actually perfectly appropriate because they are doing more than interpolating strings (even though that's what `STR` is doing). They are also supposed to safely escape the contents of the values.
