Raw String Literals

Brian Goetz brian.goetz at oracle.com
Fri Mar 23 14:05:28 UTC 2018

These arguments all boil down to a subjective "I like my syntax better, 
and I like the anomalies in my version better."  Which is fine, you're 
welcome to that opinion, and some others might even share it, but 
please, let's be honest about it -- these are your subjective opinion 
about what you like better or worse.  Let's not present them as 
universal truth.

Further, personal criticism ("it's just you"), overblown rhetoric 
("design flaw in the language"), and aggressive demands for proof of 
opinions that disagree with yours are not a constructive form of 
discourse here -- and surely not an effective way to persuade people 
over to your opinion.  So please dial it down.  The people who worked on 
this feature worked hard to consider all the tradeoffs -- as evidenced 
by the fact that all the concerns you raised had in fact already been 
considered.  You may disagree with their conclusions, or wish to 
persuade them to reconsider, but if you're going to question their 
competence, please do it privately.

On 3/23/2018 3:55 AM, Stephen Colebourne wrote:
> 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

More information about the amber-dev mailing list