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
([email protected]) 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
<[email protected]> 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
<[email protected]> wrote:
On Jul 14, 2017, at 10:00, Alex Blewitt <[email protected]> wrote:
On 13 Jul 2017, at 23:14, David Hart via swift-evolution
<[email protected]> wrote:
On 14 Jul 2017, at 00:21, Jordan Rose <[email protected]> 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
[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]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
