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

[Adrian Zubarev]

This is the natural way of text blocks. If you really need a blank line you can add one at the start/end or alternatively use \n.

"""

Foo  

"""

// Equals "\nFoo\n"


-- 
Adrian Zubarev
Sent with Airmail

Am 19. April 2017 um 22:53:07, Vladimir.S via swift-evolution (swift-evolution at swift.org) schrieb:

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/0d5ebfe5/attachment.html>