Proposal Link:
https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
<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
"""
// 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
