Revisit the String template syntax

[Brian Goetz]

The backslash syntax is objectively better than the dollar-sign syntax, which is why we selected it in the first place.  Reasons included: 

 - Today, “${name}” is a valid string literal, whereas “\{name}” is not. 
 - The language already has an escaping mechanism for string contexts; using the one we have is preferable to inventing another one.
 - Dollar signs will appear in string context fairly regularly, and therefore would need yet more escaping.  

We knew people would say “why don’t you ‘just’ do what ${MyFavoriteLanguage} does”, but this isn’t a reason to reconsider; the fact that other languages have continued to use the dollar-sign convention was well in evidence when the initial design choices were made, and there are no new arguments to support revisiting this question.

Whether to use braces or parens or brackets is largely an arbitrary choice, but I don’t see a lot of reason to recall this already-sailing ship.  



> On Apr 11, 2023, at 2:32 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> I've promoted this email to amber-spec-experts given that several people on the internet and offline have said more or less the same thing.
> 
> Even if it's not for 21, now that a string template is always prefixed by a template processor, the part in between quote does not need to rely on backslash '\' anymore.
> 
> Should we still keep the current syntax \{...} or should we go to the more usual ${...} syntax ?
> 
> regards,
> Rémi
> 
> ----- Original Message -----
>> From: "Octavia Togami" <octavia.togami at gmail.com>
>> To: "amber-spec-comments" <amber-spec-comments at openjdk.org>
>> Sent: Tuesday, April 11, 2023 1:39:20 AM
>> Subject: Syntax question for JEP 430: String Templates
> 
>> Hi,
>> 
>> I was reading this portion of the alternatives section:
>> 
>>> For the syntax of embedded expressions we considered using ${...}, but that
>>> would require a tag on string templates (either a prefix or a delimiter other
>>> than ") to avoid conflicts with legacy code.
>> 
>> And it seems that this is no longer a valid reason, as per [1] there
>> is always a required prefix anyways. Is there another reason to avoid
>> using this syntax now?
>> 
>> Thanks,
>> Octavia
>> 
>> [1]:
>> https://mail.openjdk.org/pipermail/amber-spec-experts/2022-October/003631.html