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

[Vladimir.S]

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
>