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]
>> <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
