Draft JEP: Raw String Literals

[Roger Riggs]

Hi,

Yes, this will make putting arbitrary strings in source files much easier.

About the choice of delimiter.
"Delimiters should have a low profile for small character sequences, 
margin management, and general readability"

I would be concerned about the backtick on two points:
   1) it has such a low profile that developers will miss the detail 
that the string contents are *different* and
   2) and that in other contexts, such as a shell, the backtick implies 
an interpretation or evaluation of the string.

As Stephen observed, it would be nice to have a syntax to indicate 
conversion of constants for known types.
Perhaps along with type inference it might be nice to be able to say:
    LocalDate first = `2018-01-01`;        // With some binding to 
.valueOf methods...

I'm not clear on how the idea for methods to handle margins, (1st line 
vs rest) can be realized
once the string is a string.

It might be worth noting whether the String concatenation of string 
literals and raw string literals
works as expected.  (That they are concatenated).     `abc` + "xyz" == 
"abcxyz".

$.02, Roger


On 1/29/2018 7:51 PM, Stuart Marks wrote:
> On 1/27/18 6:43 AM, Jim Laskey wrote:
>> The time has come to revisit strings in terms of the modern 
>> development world. “Java remains one of a small group of contemporary 
>> programming languages that do not provide language-level support for 
>> raw strings.”
>>
>> This JEP proposes the introduction of Raw String Literals into the 
>> Java Language.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8196004 
>> <https://bugs.openjdk.java.net/browse/JDK-8196004>
>
> Nicely written, and this facility is certainly needed.
>
> Regarding the choice of delimiter, I suspect this is one of those 
> things where there are multiple camps that all disagree with each 
> other. No matter which one you choose (and yes, you should choose one) 
> the others are going to complain.
>
> **
>
> I think the senses of the escape() and unescape() library calls are 
> backwards as proposed. To me, "escaping" something means replacing 
> some data with an alternative form -- an escape sequence -- that can 
> be dealt with more conveniently, e.g. that can be typed on a keyboard, 
> and that is visible on a printout. For example, consider a string that 
> contains
>
>     U+000A LINE FEED
>
> "Escaping" this string means turning this control character into a 
> sequence of printable, typable characters:
>
>     U+005C REVERSE SOLIDUS
>     U+006E LATIN SMALL LETTER N
>
> (that is, \ followed by n).
>
> And "unescaping" is the opposite, to remove escape sequences from a 
> string by replacing them with the character data they represent.
>
> Both of the following would be true:
>
>     "\n".escape().equals(`\n`)
>     `\n`.unescape().equals("\n")
>
> And, if the mailer doesn't screw up the spacing, the expressions below 
> are equivalent to those above, and both would also be true:
>
>     `
> `.escape().equals(`\n`)
>
> and
>
>     `\n`.unescape().equals(`
> `)
>
> Thus, we have escape() defined as "to process a string into escape 
> sequences" and unescape() defined as "to remove escape sequences by 
> replacing them with the character data they represent". I haven't been 
> able to find anything definitive that supports this sense, but it does 
> seem to agree with common parlance (e.g., blog posts, Stack Overflow 
> questions).
>
> The proposal currently has escape() meaning "to process escape 
> sequences into original character data" which is sort of sensible. But 
> then unescape() means to *add* escape sequences, which seems very odd. 
> For that reason I prefer the opposite senses.
>
> Thanks,
>
> s'marks