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

[David Hart]

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 <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 <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> 
>>> On Jul 14, 2017, at 10:00, Alex Blewitt <alblue at apple.com <mailto:alblue at apple.com>> wrote:
>>> 
>>>> On 13 Jul 2017, at 23:14, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>>> 
>>>>> On 14 Jul 2017, at 00:21, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> 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
>> 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/20170717/3043b95f/attachment.html>