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

Wed Apr 19 17:16:45 CDT 2017

We had a very full debate about which way was superior during review; it
was proposed to behave one way and the core team decided on the other. We
have to let settled decisions be settled: that's the only way Swift
Evolution will continue to work.

On Wed, Apr 19, 2017 at 5:15 PM, Kevin Nattinger via swift-evolution <
swift-evolution at swift.org> wrote:

> 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>:
>
> 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) 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
> 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
> 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/1942f716/attachment.html>