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 >> >