Hi,
I think, it would be more natural to include the last newline.
Multi-line String literals are for multiple lines.
And each line ends in a \n. Otherwise it wouldn’t be a line.
Having
"""
line 1
"""
+
"""
line 2
"""
==
"""
line 1
line 2
"""
makes a lot of sense to me.
Or do we want to magically add a trailing newline everywhere as we do in
print()?
Better change print to only add the newline when necessary! (e.g. by adding a
new parameter which defaults to „auto“)
—
Martin
> Am 19.04.2017 um 23:51 schrieb Adrian Zubarev via swift-evolution
> <[email protected]>:
>
> 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
> ([email protected] <mailto:[email protected]>) 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
>> > [email protected]
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
