[swift-evolution] multi-line string literals

[Brent Royal-Gordon]

> I'm not entirely sure how to respond to this, but I think some of your suggestions might go against the goal of having less noise in defining a multi-line string. It's actually more to type than:
> "this is the first line \n" +
> "this is the second line \n"
> ​...which we can already do.
> 
> Your suggestion that each line should end in \n makes me think you're actually trying to have a bit of fun with me, but I can't really tell and I really don't want to be rude by making that assumption.

I am being serious. This proposal does require more characters, it’s true. However, it doesn’t require more *reading*—because the leading indicators will generally line up, you can ignore them and read everything to the right, like the “> “ used to demarcate your text above from my text—and with an editor feature to select several lines and quote them (the way you can with comments in most editors), it wouldn’t require more *writing* either. And although it uses more characters, it *also* unmistakably sets off quoted material from code, comments, other multiline string literals, and anything else, while being unambiguous about whether indentation is intended to style the literal or be part of it, without a bunch of funky obscure modifier characters like "<<-END".

The \n thing was an idle thought being presented for discussion, not a concrete suggestion, but it was also not a joke. (I realized after sending it, however, that the trailing newline problem can be solved by simply having a rule that you strip one trailing newline. If you want your string to end with a newline, include a sacrificial blank “Foo>” line at the end of the literal. Some sort of modifier to indicate the trailing newline behavior is possible too, but see the previous paragraph for my thoughts on those.)

I’ve used and loved heredocs in Perl and Ruby, but I always understood that they have significant problems. That experience shaped this proposal.

-- 
Brent Royal-Gordon
Architechies