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

[Kevin Nattinger]

I agree, but unfortunately it’s probably too late now.

> On Apr 19, 2017, at 3:11 PM, Martin Waitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <mailto: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 <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 <mailto:swift-evolution at swift.org>
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution <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
>> 
>> 
>> _______________________________________________
>> 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>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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