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 <[email protected]> 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" <[email protected]>
>> To: "amber-spec-comments" <[email protected]>
>> 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
