Raw String Literals Revisions

[Brian Goetz]

> Based on input received since the reveal of https://bugs.openjdk.java.net/browse/JDK-8196004
> Raw String Literals, we propose making the following changes.
>
> - We will be extending the definition of raw string literals to allow
>    repeating backticks (ala Markdown.)

The benefit of this is that, for a suitably chosen delimiter, any 
document can be embedded with no loss of fidelity.  For embedded 
documents that use ` in them, choose a suitable delimiter (usually `` 
will be enough) and paste away.  We stated earlier that it was a goal to 
make raw string literals truly free of interpretation by the lexer; this 
removes one of the remaining bits of non-raw-ness, that embedded 
backticks required some minor escaping.   (The other remaining bit is 
the treatment of newlines; not sure how much its worth doing here to 
support platform-specific line endings.)  If people really want 
platform-specific newlines, they can toss a .replace("\n", "\r\n") on 
the end (which is amenable to the same optimizations as .trimIndent()).

> - The naming of the the “escape" and “unescape" String methods will be
>    reversed such that “unescape" converts escape sequences to characters
>    and “escape" converts worthy characters to escape sequences. Some more
>    thought could be given to these names 1) to address the overloaded use
>    in other languages, ex. JavaScript HTML escaping, 2) truly make the
>    direction of conversion clear.

I think this is a better polarity, but I think this exercise shows that 
"escape" and "unescape" may still be too-confusing names.  I suggest we 
continue the search for names that shout out their directionality.

>              
>    Ultimately, ignoring escapes, we would end up with two ways of do the
>    same thing. Thus, we will not be supporting multi-line traditional
>    strings at this time.

I think this is the right move, though there are arguments on both sides 
here.  The new feature is raw string literals, which are designed for 
embedding longer (but not too long) snippets of text free of Java 
interpretation.  For the rare cases where people want both string 
escaping and multi-line, there are library tools for adding back the 
escaping.