Raw String Literals

[Stephen Colebourne]

On 21 March 2018 at 15:10, Jim Laskey <james.laskey at oracle.com> wrote:
> We think things have "settled in" with respect to Raw String Literals language changes and library support. If all things fall in place, we will probably move http://openjdk.java.net/jeps/326 forward soon.

What does this print?

public void varargs(String... strs) {
  System.out.println(Stream.of(strs).collect(joining()));
}

varargs(`Hello`, ``, ` World! `, ``);

.


scroll down for the answer...


.


.


Answer: "Hello, `World!`, " (notice the extra commas, because there
are only 2 arguments, not 4, due to no raw string literals)
(thanks to Kevin B for the puzzler)

As I have stated elsewhere, I believe the trade offs in the raw string
literal proposal are poor for Java. Not allowing an empty string and
not allowing strings to start or end with backticks is surprising, and
I believe the puzzler demonstrates the nasty effects of excluding an
empty string literal (as also demonstrated here
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052052.html).
I do understand the appeal of being able to self-embed (the "stress
test"), I just happen to think it is the wrong trade off.


Fortunately, I believe there is a way for Java to have both empty raw
string literals and full embedding. Simply disallow double backtick as
a delimiter.

`foo` = "foo" (single backtick)
`` = "" (empty string)
``foo`` = compile error
```foo``` - "foo" (triple backtick)
`````` - compile error (no empty string here)
`````foo````` - "foo" (five backticks)

There is a major specification that separates one backtick from three
backticks - Markdown:
 http://spec.commonmark.org/0.27/#code-spans
 http://spec.commonmark.org/0.27/#fenced-code-blocks
As such, I think this would be readily accepted by developers, who are
often familiar with Markdown.

Were this approach to be adopted, I believe single backtick literals
should not allow new lines. This would be a good simplification, and
probably help IDE error recovery in many cases. The 3+ backtick
literals would behave as per the current Oracle proposal, but with the
benefit that when embedding just one or two backticks developers will
not need to see or learn the rule about unlimited backticks. Thinks
like regex would tend to use single backticks, while things like
embedding XML or Javascript would use 3+ backticks.

In summary, not allowing an empty raw string is going to result in
nasty puzzlers, and IMO unlimited delimiters by themselves is not in
the spirit of Java. Following Markdown's approach of separation
between single and 3+ backticks would provide considerable benefits to
Java.

Stephen