Jan,
Yes, thanks for clarifying my comment.
And to repeat, my comment was just to raise awareness in the different
treatment according to JLS and to .unescape().
-- Jon
On 9/19/18 7:10 AM, Jan Lahoda wrote:
I guess Jon's comment was that (per JLS) the outcome of unicode
unescapes can then participate in the escape sequences in String
literals. So, this:
"\u005ct"
is (as far as I know) a single character-literal (a tab), while it
seems that
`\u005ct`.unescape()
is two characters:
\t
Not sure if that's an intent or not.
Jan
On 18.9.2018 20:55, Jim Laskey wrote:
The intent, of course, is to offset the raw string literals
non-translation of Unicode escapes and escape sequences. That is,
have the multi-line cake and eat the escapes too.
So a developer could have
String s = `
\t\tTitle
\t\t\tbody
...
`.align().escape();
to have tabs inserted in the string.
"\\" "\u005c\u005c" and `\` all translate to the same string.
`\u005c` translates to "\\u005c”. `\u005c`.unescape() thustranslates
to be the same as "\\”, "\u005c\u005c" and `\`.
Cheers,
— Jim
On Sep 18, 2018, at 3:33 PM, Jonathan Gibbons
<jonathan.gibb...@oracle.com> wrote:
Jim,
In JLS, and hence javac, Unicode escape handling happens early on at
a low level, before string escape handling. This means that it is
technically possible to write string escape sequences in terms of
Unicode escapes.
I'm not suggesting you should do the same here, but you should be
aware of the difference, compared to javac behavior.
-- Jon
On 9/18/18 10:51 AM, Jim Laskey wrote:
Please review the code for String::unescape. Used to translate
escape sequences in a string, typically in a raw string literal,
into characters represented by those escapes.
webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
csr: https://bugs.openjdk.java.net/browse/JDK-8202443
Cheers,
— Jim
