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

[Martin Waitz]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170420/87e0970d/attachment.html>