[swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

[Ricardo Parada]

If I understood Joe correctly he said it gets stripped:

"a single newline is always stripped after the opening delimiter and before the closing one, and the closing delimiter's position always determines the indentation level of the entire literal."

So I think it would be "foo\nbar". 

> On Apr 19, 2017, at 4:52 PM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On 19.04.2017 23:03, Joe Groff via swift-evolution wrote:
>> Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>> Hello Swift Community,
>> The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The proposal is *accepted with revisions. *Community feedback was largely positive on the idea, though the discussion highlighted several under-specified aspects.
>> - Questions arose about whether text could appear on the same line as the opening and closing delimiter, and how that would interact with the de-indentation algorithm. The core team feels that it is important to keep this feature focused on its purpose of allowing the easy embedding of pasted blocks of text, so *text inside the literal on the same line as either delimiter should be disallowed.*
>>    // Allowed, equal to "foo\nbar"
>>    """
>>       foo
>>       bar
>>       """
> 
> Could you clarify, shouldn't this be equal to "foo\nbar\n" ? I.e. with trailing \n for "bar" line?
> I didn't find any clarification about the injecting of line-end for last text line(not for the """ delimiter).
> 
>>    // Not allowed
>>    """foo
>>       bar
>>       """
>>    // Not allowed
>>    """
>>       foo
>>       bar"""
>> This keeps the model straightforward to describe: a *single newline *is always stripped after the opening delimiter and before the closing one, and the closing delimiter's position always determines the indentation level of the entire literal. The core team acknowledges that single-line triple quoted strings have other uses in other languages, such as to avoid excessive escaping in a string that contains lots of literal quotes, but supporting that alongside the indentation-stripping behavior leads to a lot of subtlety, and there could be other solutions to the escaping problem down the line, such as raw strings. If nothing else, single-line triple quoted strings can be considered later as an additive feature.
>> - The core team also believes that *underindentation or inconsistent tab/space usage within the indentation should be an error.* Every line inside the literal must begin with the exact sequence of spaces and tabs that precedes the closing delimiter.
>> """
>> <tab><space>this is OK
>> <space><space>this is an error
>> <space><tab>this is also an error
>> <tab>under-indenting is an error too
>> <tab><space><space>but you can go nuts after the indentation all you want
>> <tab><space><tab>you do you
>> <tab><space>"""
>> - The quoted string should *normalize newlines* to \n in the value of the literal, regardless of whether the source file uses \n (Unix), \r\n (Windows), or \r (classic Mac) line endings. Likewise, when the compiler strips the initial and final newline from the literal value, it will strip one of any of the \n, \r\n, or \r line-ending sequences from both ends of the literal.
>> // equal to "foo\nfoo\nfoo\nfoo"
>> """^J
>>   foo^M^J
>>   foo^J
>>   foo^M
>>   foo^M
>>   """
>> - It should be clarified that *multiline strings support the same escapes and interpolations* as single-line strings. This allows a literal """ to be written \""". Discussion on the list raised the idea of allowing a line to end with \ to "escape" the newline and elide it from the value of the literal; the core team had concerns about only allowing that inside multi-line literals and felt that that could also be considered later as an additive feature.
>> Thanks John, Brent, and Tyler for the original proposal, and thanks to everyone who participated in the discussion!
>> -Joe
>> Review Manager
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170419/b9014800/attachment.html>