If you're making the change, then you might add a test case based on
Jan's suggestion, testing
"\u005ct".equals(`\u005ct`.unescape())
-- Jon
On 9/19/18 7:40 AM, Jim Laskey wrote:
I see and good point. I think Jon is correct. If you are using the JLS as the
basis of your argument, then you better damn well stick to the JLS.
I’ll make the changes.
Cheers,
— Jim
On Sep 19, 2018, at 11:10 AM, Jan Lahoda <jan.lah...@oracle.com> 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
