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 <[email protected]>
> 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
>>
>
