revised webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev-02/index.html
> On Sep 19, 2018, at 11:57 AM, Jim Laskey <james.las...@oracle.com> wrote: > > Will do. > > >> On Sep 19, 2018, at 11:42 AM, Jonathan Gibbons <jonathan.gibb...@oracle.com> >> wrote: >> >> 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 >>>>>>> >> >
