[raw-strings] Newline character handling

[Tagir Valeev]

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 <forax at univ-mlv.fr> 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" <amaembo at gmail.com>
>> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>> 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/