Ah, indeed. Missed this part somehow. Sorry for the noise then. With best regards, Tagir Valeev.
On Sat, Jan 27, 2018 at 5:59 PM, Remi Forax <[email protected]> wrote: > Hi Tagir, > you have miss this line: > CR (\u000D) and CRLF (\u000D\u000A) sequences are always translated to LF > (\u000A). This translation provides least surprise behavior across platforms. > > this is also the behavior of Perl, PHP, etc. > > as a guy that had to write too many shaders in Java recently, thanks for > resurrecting this discussion, i think we should not wait another 10 years to > add raw strings in Java. > > regards, > Rémi > > ----- Mail original ----- >> De: "Tagir Valeev" <[email protected]> >> À: "amber-spec-experts" <[email protected]> >> Envoyé: Samedi 27 Janvier 2018 05:13:58 >> Objet: [raw-strings] Newline character handling > >> Hello! >> >> I looked through Raw String Literals JEP draft [1] and did not find >> any explicit statement about CR/LF translation within multiline raw >> string. Usually in text files (and, I believe, Java source qualifies >> as a text file) it's assumed that changing \n to \r\n and vice versa >> would not change the semantics. Sometimes such changes are performed >> automatically, e.g. on Git checkout via core.autocrlf=true setting >> [2]. If multiline string literal is used, then such replacement may >> badly affect the semantics of the program. E.g.: >> >> public class Hello { >> public static void main(String[] args) { >> System.out.println(`Hello >> World!`.length()); >> } >> } >> >> The output of this program may change if its source text is converted >> from CR/LF to LF line endings or vice versa. >> >> As far as I know, Kotlin forcibly replaces CR/LF to LF within >> multiline strings, though I did not find any explicit statement about >> this in the documentation. This looks a good compromise, though could >> be annoying for people who actually want to encode CR/LF inside a >> multiline string. Nevertheless, I feel, that the special handling of >> line terminators within multiline strings (or absence of such >> handling) should be explicitly mentioned in the JEP and the following >> specification. >> >> With best regards, >> Tagir Valeev. >> >> >> [1] http://openjdk.java.net/jeps/8196004 >> [2] https://help.github.com/articles/dealing-with-line-endings/
