[swift-evolution] [Review] SE-0182 - String Newline Escaping

Mon Jul 17 07:25:13 CDT 2017

I only had a quick glance but I quickly noticed that there were quite a lot cases which didn’t require a trailing new line, but if we’d revert this decision would require a trailing \ over and over.

That would make the simplest multi-line string literal not that simple anymore:

"""
abc
""" == "abc\n"
Which means we’ll see a lot of cases like:

"""
abc\
"""
I obviously cannot foresee which cases would dominate, but I’d keep it like it is. Furthermore, we wanted to avoid this talk in this review anyway.

On the other side the ability to write \ in the last line can be used in cases like this:

let signatureTemplate = """
    Adrian Zubarev
    Sent with \
    """

// At some later point
let clientName = "Airmail"
print(signatureTemplate + clientName)

// prints:
// Adrian Zubarev
// Sent with Airmail
And I still don’t see the need for adding this feature to " literals. That’s only my personal opinion! We don’t want to align Swift with other languages, especially not with the C-family. Sure we want interoperability, but that can be achieved differently. Our goal is to borrow best practices or improve things know from other languages so that we can avoid ugliness baked into other programming languages. If we’re speak about consistency for \ than we should speak about consistency between the two literals and not other languages.

// #1
// What does this version add to Swift (forget other languages)?!
_ = "Swift \
is awesome"

// #2 - Consistent counterpart for #1  
// (already rejected in SE-168 for good reasons)
_ = """Swift \
is awesome"""

// In theory #2 still would have indent stripping.
// This makes #1 inconsistent!
_ = """Swift \
    is \
    awesome"""

// I also don't think we want to debate about the  
// combination like the following one:
_ = """Swift \
    is \
    awesome
    """

// #3
"""
Abc
Def
"""

// #4 - Consistent counterpart for #3
// `"`- literal should stay explicit about it's content.
// Does this add anything that `"""` cannot solve better? - No!
"
Abc\n
Def\n
"

-- 
Adrian Zubarev
Sent with Airmail

On 17. July 2017 at 13:43:07, David Hart via swift-evolution (swift-evolution at swift.org) wrote:

To add a data point, I migrated the Swift Package Manager to use Swift 4’s multi-line strings this weekend. Nearly all of the resulting multi-line strings required an ending new-line, forcing me to write the following pattern everywhere:

let text = ""”
    lorem ipsum dolor sit amet
    consectetur adipiscing elit
    sed do eiusmod

    “""

I agree that the Swift Package Manager is only one data-point, that mostly uses multi-line strings to append string content to files. Another project with SQL queries in multi-line strings might not really want an ending newline.

For reference, here is the Pull Request: https://github.com/apple/swift-package-manager/pull/1272/files

David.

On 17 Jul 2017, at 13:32, John Holdsworth via swift-evolution <swift-evolution at swift.org> wrote:

As this review winds down it seems fair to say the response has been generally
favourable with some reservations about whether this should be applied to single
line strings as well. I’d include single line strings myself for consistency with multi-
line and with other languages myself but that isn’t the focus of this proposal.

There has also been some discussion about whether escaping the last newline should
be an error or ignored. For me this highlights that the final newline should be included
in the literal and could therefore be escaped when you want one without a newline at
the end which may or may not be the common use case as has been discussed before.

let text = """
    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod \
    tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, \
    quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.\
    """

let endsWithNewline = """
    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
    tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
    quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    """

While multi-line strings would loose their pleasing symmetry from SE-0168 where initial
and final newlines are stripped I'd argue in response that text is generally asymmetric
with files generally having no newline at the start and a newline at the end. I can see
the arguments for both decisions though and could live with either.

-John

On 14 Jul 2017, at 18:17, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:

On Jul 14, 2017, at 10:00, Alex Blewitt <alblue at apple.com> wrote:

On 13 Jul 2017, at 23:14, David Hart via swift-evolution <swift-evolution at swift.org> wrote:

On 14 Jul 2017, at 00:21, Jordan Rose <jordan_rose at apple.com> wrote:

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md]

This is a tiny, tiny point amidst the broader discussions others are having, but

• All whitespace characters between \ and the newline are disregarded.

Why? Why bother allowing whitespace characters between \ and the newline?

The reasoning is to be consistent with trailing whitespace in the rest of the code: to leave that to a linter instead. Or to see it differently, even with whitespace between \ and the newline, the programmer’s intent is still clear. Why generate an error?

For the same reason that code allows (e.g.) a comment at the end of the line; you wouldn't expect (newline continuation) (comment) to mean the same thing as if generic whitespace were added at the end. The convention in other languages is that \ immediately precedes the line feed to indicate a continuation, not that an orphan \ is valid on its own.

The reason that \(newline) is valid while \(otherchar)(newline) isn't is because \ immediately precedes another character that it is escaping, and it's possible that \(space) would have a meaning in the future, whereas \(newline) won't.

I agree with Alex on this, although I would be happy to make it a warning rather than an error so that it doesn't block compilation.

The point about comments is also significant: we previously said that comments should generally be treated like whitespace (SE-0037). This is a little different because it's still inside the string literal, but it's probably worth explicitly stating "we're still inside a string literal; you can't just put comments after the backslash".

Jordan

_______________________________________________
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/20170717/6347c042/attachment.html>