[sitta]

The comments about this feature are always so tiresome. Please just scroll down and read the "Alternatives" section at the bottom. They're not idiots. They're working within backwards compatibility constraints. They can't just do it like other languages.

[david_allison]

C# introduced `#nullable enable` to change the behaviour of reference types.

Java could do the same to change the behaviour of `$` inside a string (along with a project-level config to make this the default).

Let developers opt-in to better syntax, rather than using significantly worse syntax to support legacy code

https://learn.microsoft.com/en-us/dotnet/csharp/nullable-mig...

[ghusbands]

It's moot, anyway, as parser changes are already required by the STR." part. About the only possible defence is that one could use the same lexer, but even that's not true because you can presumably now embed a multi-line string in a single-line string, like so:

  STR."\{STR."""
  \{hey}
  """}"

[vlakreeh]

Even with their constraints they could have made this nicer, especially around the default formatter. Always requiring an explicit formatter is a classic example of Java being unnecessarily verbose, `\{ ` already wasn't permitted by previous java compilers as it was an unknown escape sequence so we could have nicer templates for the stock formatting like "\{foo} bar".

[rco8786]

All super weak arguments IMO. Problems that somehow every other language doesn’t have?

[marginalia_nu]

Other languages are not attempting to be backwards compatible with Java.

[rco8786]

One of the arguments is that existing $ in strings would have to be escaped. Every other language supported $ in strings before interpolation appeared. Not Java specific.

Every other language is susceptible to SQL injection style attacks. Not Java specific.

[marginalia_nu]

Few other languages are as committed to backwards compatibility as Java though.

[wiseowise]

Super weak how? They're quite reasonable and weighed-out.

[troupo]

Those are extremely weak arguments.

Elixir has string interpolation and custom "templates" or whatever they are called without the ugly syntax:

  ~h"custom one"
  ~s"custom two"

etc.

[jitl]

~x”hi” is basically the same amount of ugly to me as X.”hi”

[troupo]

I find it significantly less jarring than STR."hi"

[ioasuncvinvaer]

How are these interpolated?

[sergiotapia]

I think most people read the whole thing. I have. It's still very ugly

[_old_dude_]

You can not use the excuse of the backward compatibility twice.

If the string template is prefixed by a processor STR."foo" instead of "foo" then you do not need \{variable} instead of $variable.

[usrusr]

You don't want friction on the default path to be too low because that would inevitably increase the occurrence of default path where it must not be used, e.g. cause sql injections.

Much easier to accidentally write something that boils down to

   "\{bobby}" 

where it should have been

   SQL."\{bobby}"

than

   STR."\{bobby}"

instead of

   SQL."\{bobby}"

(i admit that this argument would work better if STR was typographically more different from the name you'd inevitably use for an SQL statement processor)

[jitl]

They want to ensure the new interpolation sequence is a compiler error in non-template strings, so that the incorrect “hi \{name}” is an error instead of silently doing the wrong thing. Using \{ accomplished this because it’s an unknown escape sequence in older Java (so forbidden there), and in new Java will have the more specific error of “yo you forgot the template processor at the start of your template”.

[_old_dude_]

Yes, you do not get a compile time error, but visually a big STR is front is enough "${variable}" vs STR."${variable}"

And editors will use different colors.

Using \ or $ is not about backward compatibility but about ergonomics.