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
<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] <mailto:[email protected]>> wrote:
>>
>>
>>
>>> On Jul 14, 2017, at 10:00, Alex Blewitt <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>> On 13 Jul 2017, at 23:14, David Hart via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>>>
>>>>> On 14 Jul 2017, at 00:21, Jordan Rose <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> [Proposal:
>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
>>>>>
>>>>> <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
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md>).
>> 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] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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
