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@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.mdHello 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution