<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/12/2023 4:42 PM, Eran Leshem
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:02a101da15b1$1b0e2f00$512a8d00$@leshem.life">
      
      <meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
      <style>@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
        {font-family:"Freestyle Script";
        panose-1:3 8 4 2 3 2 5 11 4 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}h2
        {mso-style-priority:9;
        mso-style-link:"Heading 2 Char";
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:18.0pt;
        font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}span.Heading2Char
        {mso-style-name:"Heading 2 Char";
        mso-style-priority:9;
        mso-style-link:"Heading 2";
        font-family:"Times New Roman","serif";
        font-weight:bold;}.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}div.WordSection1
        {page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Hello,<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I’m delighted by the addition of String
          Templates to Java! <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I have a question about the syntax. The
          Alternatives section of the JEP gives great answers to most
          questions, but I was left with this one:<o:p></o:p></p>
        <p class="MsoNormal">Why is the backslash needed? In most
          languages, as you nicely listed, string templates are marked
          with either a template prefix or an embedded expression
          prefix. Why does Java require both the “<processor>.”
          template prefix and the “\” embedded expression prefix? <o:p></o:p></p>
      </div>
    </blockquote>
    <br>
    There were a number of reasons for this choice, which was made in
    the light of the many different choices other languages have made
    (and their pros and cons) and the consequences for _adding_ this as
    a feature to Java (as opposed to if it had been part of the language
    from day 1.)  <br>
    <br>
    One proximate reason is uniformity and migration; Java programs are
    full of string literals today (which are sometimes used as templates
    for String::format and the like), and many of them have dollar signs
    already.  And a string literal / text block with _no_ embedded
    expressions can still be used in a template expression, and means
    the obvious thing, and this is both uniform and useful.  If all
    strings _except those with dollar signs_ were valid in template
    expressions, but dollar signs had to be escaped, this means
    migrating existing code to use template expressions forces the user
    to scan the entirety of their string (which could be many lines
    long) to search for dollar signs and escape them, or risk making a
    mistake.  That's terrible, and unnecessary.  <br>
    <br>
    While it might be possible to rescue the ${blah} syntax if it were
    indeed great, in actually this syntax is terrible; we're all just so
    used to it that we've stopped seeing how awful it is.  The $
    character is common in strings, which makes this error prone (using
    $ instead of \$ or however it would be escaped) and also means that
    strings with dollar signs are less readable.  A string literal is
    supposed to be a sequence of characters; while every string literal
    feature needs some sort of escape mechanism to handle non-printable
    characters, having two different escape mechanisms ($ for
    interpolation, \ for weird characters), each with their own special
    rules, is unnecessarily irregular.  It was not worth doing any work
    to rescue this syntax, just because it is familiar from some other
    languages.  We have an escape mechanism, which was easily extendible
    to this approach (and Swift's experience shows that the \{...}
    mechanism is perfectly usable.)  <br>
    <br>
    I can sort of see how you might want to characterize the processor
    as a "template prefix", but it is not; it is something else.  The
    template expression syntax is built on the string literal / text
    block syntax, and adding extra complexity just to rescue a fatally
    flawed (albeit familiar) syntax would have been a bad choice.  <br>
    <br>
    <blockquote type="cite" cite="mid:02a101da15b1$1b0e2f00$512a8d00$@leshem.life">
      <div class="WordSection1">
        <p class="MsoNormal">The Ensuring Safety section implies that
          the backslash’s goal is to enable the detection of string
          templates with missing processors. Did I read that correctly?
          If so, I’d suggest documenting that explicitly. In addition,
          I’d like to raise the question whether the extra ceremony is
          warranted by that goal.</p>
      </div>
    </blockquote>
    <br>
    That was not the "goal"; it is merely one of its benefits.  The main
    reason to prefer backslash here is that strings _already have an
    escape mechanism_, and we should use the existing escape mechanism
    rather than inventing a new and different one.  This guarantees that
    existing strings can be used seamlessly with the new feature; it
    minimizes linguistic complexity and the activation energy of
    learning the language; and it reduces errors.  <br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>