[swift-evolution] multi-line string literals

[Chris Lattner]

On Dec 14, 2015, at 3:51 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> Yes, you are right, Brent, there should be a closing quote on the last line otherwise it would be a syntax error. That’s a much better idea! That would also fix the 
>> 
>> let x = “foo
>> 
>> being valid syntax problem.
> 
> So, based on this idea, here’s what I propose. We have two orthogonal features:
> 
> ADJUSTABLE DELIMITERS:
> 
> Any odd number of “ characters can be used to delimit a quoted string. That means you can start and end one with “, “””, “””””, “””””””, etc. (In practice, more than three would probably only be used when generating code which itself includes multiline strings.) This only affects how many quotes in a row you have to backslash inside the string; it does not imply the string is multiline.

This is an interesting approach to avoid having to escape “’s in some common situations.  One corner case: how do you write a string literal that starts or ends with “?    How do you express the equivalent of “\”foo”?  A concern is that this could make escape processing “feel” less predictable.

> MULTILINE STRINGS:
> 
> If a quoted string does not terminate by the end of the line, Swift examines the next line of code. If that line starts with zero or more whitespace characters, followed by the same string delimiter used to open the string on the previous line, then the string literal includes the newline character at the end of the previous line and then continues on the next line.
> 
> If the next line has anything else before the delimiter—including a string delimiter which is not long enough, a comment, or a newline—Swift concludes that the string does not continue onto this line and emits an unterminated string error on the previous line. Thus, an unterminated multi-line string is always detectable in and of itself.
> 
> Swift does not do any other special processing of the string, like removing indentation (all indentation should be before the string delimiter on that line) or trimming newlines at the beginning or end. All escapes function as normal; any modification of escaping is reserved for other mechanisms outside the scope of this thread.

This sounds very interesting, and could be workable, I agree that this solves the error recovery problem.  I still think we’d want a way to disable escape processing.

-Chris