Raw String Literals

[Stephen Colebourne]

On 22 March 2018 at 19:29, John Rose <john.r.rose at oracle.com> wrote:
> I didn't need to scroll down; it was obvious to me.  Perhaps because
> I've spent a little more time gaining experience with Jim's proposal.
> But maybe that's just me?

Yes it is, sorry. I've spent time with the feature too, yet it still
got me on first showing. Rather than denying it, the correct question
to be asking is why?

Two things combine - a deep held expectation about empty strings, and
the fact that in visual terms the comma grabs the eye as the argument
separator. I saw 4 arguments, carried on reading the email and a few
seconds later realised that I was being shown a puzzler, and had to go
back and figure it out.

> The only downside you mention is the puzzler you found.

No. The puzzler is evidence of a design flaw in the language feature.
Something that language designers should be very wary of. The
problem/downside is breaking a fundamental expectation of users - that
empty strings exist. In the spec-experts emails and beyond discussing
this feature, I don't think the lack of empty raw string has been
widely tested.

> Can you guarantee that your more complex proposal has no such
> puzzlers of its own?

Any puzzler that applies to 3+ backticks in Oracle's proposal also
applies to my proposal.

Any puzzler that revolves around the empty string necessarily applies
only to Oracle's proposal because of the lack of empty string support.

Any puzzler that applies to single backtick blocks will have a smaller
blast radius with my proposal because it cannot contain new lines.

QED!

But, just for fun, here is another one:

public void foo() {
  output(`/n`, ``);
  var str = execute();
  output(str + `/r/n`, ``);
}

OMG!!!
(IDE colouring would help with this one, but I refer you to Stuart
Marks' recent var style guide - "P3. Code readability shouldn't depend
on IDEs")


On 22 March 2018 at 19:23, Jim Laskey <james.laskey at oracle.com> wrote:
> 1. The assumption that developers are unable to see double-backtick as anything other than an empty string is not valid.

You've done a survey to show this? Got some other proof? I'd argue
forcefully that it is deeply ingrained into most developers thinking
about strings that any delimiter repeated twice is the empty string.
(a char isn't a string and developers know chars can't be empty, so
its not comparable).

> 3. This “puzzler” isn’t really a puzzler; it’s just a speed bump on the way to learning the feature.

A puzzler is something that if you put up on a screen, most people get
wrong (or struggle with) potentially even if they know the rules. I
believe that is definitely the case here.

> And, IDEs will help with syntax coloring

Not in the case of this puzzler - you are relying on users noticing
the colour of two small commas.

> 4. Let’s look at the proposed alternate solution, which is to disallow double-backticks. This may look like an obvious win, because it rescues those that assume that double-backtick is the empty string. But it also creates a cost, which is borne by all users: an anomaly. Learning the rule "any number of ticks" is easier than "any number of ticks, except the second most convenient number (two) you’d probably want to use.”

Thats not how it would be described or explained though. Instead, just
like Markdown does, there would be two distinct descriptions in one
section, a simple single backtick variant and a complex multi-backtick
one. With the new line restriction on single backticks this would be
very obvious in code too. (IMO, a triple backtick a much better visual
delimiter for multi-line raw strings anyway).

> 5. Any solution will introduce puzzlers: varargs(`Hello`, ````, ` World! `, ````);.

In that case the four backtick delimiter is of such a size that it
draws the eye away from the comma and doesn't build on the deeply held
empty string concept. And anyway, this example applies to both
proposals.

Stephen