[swift-evolution] [Accepted] SE-0168: Multi-Line String Literals
svabox at gmail.com
Wed Apr 19 15:52:46 CDT 2017
On 19.04.2017 23:03, Joe Groff via swift-evolution wrote:
> Proposal Link:
> 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"
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
> // Not allowed
> 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
> - 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"
> - 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!
> Review Manager
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution