Draft JEP: Raw String Literals

[Jim Laskey]

I think there is general support for reversing the names. It was a case of escape came first and unescape was an afterthought. Personally, I would like something that upped the clarity; to/from, apply/remove.

Cheers,

— Jim


> On Jan 29, 2018, at 8:51 PM, Stuart Marks <stuart.marks at oracle.com> 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