[swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

[Xiaodi Wu]

You can use a plain text editor and no linter, or a plain text editor and a
linter, or an IDE and no linter, etc., and in any of these scenarios you
can already choose whether or not you want trailing newlines stripped. Why
should the compiler try to enforce any rules here?

Since Unicode is supported, it is never possible to look at a string
literal and be 100% sure of what glyphs are involved. We should be clear
that such a criterion cannot and should not be a design goal. If it
supports Unicode and is really literal, then confusables and invisibles
will make it impossible to be sure of what you see; you would have to
either stop supporting Unicode or stop being literal.

I'm not sure this "coding style" you describe can properly be thought of as
a multiline string literal. It sounds like what you want isn't multiline
(in fact, you want a new way to write a very long single-line string) and
it isn't literal (you want to use newlines in your code that do not
represent a literal newline). If there is something extremely critical
about a particular string, where you simply must start half of it on a
separate line to help the readers of your code understand what you are
doing, you can already do this by writing "foo" + [newline] "bar". Or you
could just let your editor soft-wrap your long string. Making your
single-line string wrap the same way in every IDE just doesn't seem like
it's related to or worth complicating the syntax for multiline string
literals. I would be strongly opposed to such a feature.


On Wed, Apr 19, 2017 at 23:42 Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> True, but this is not about IDEs or editors. The feature itself doesn’t
> know what an editor is and what it capable of, nor should be ever rely on
> that. Not everyone uses the same settings and you cannot be 100% sure to
> expect the same string from looking at it, which was written in a different
> editor if we don’t warn about trailing whitespaces now.
>
> The trailing whitespaces might not do any harm for the currently accepted
> version, but we’ll have to warn about them if we decide to add the trailing
> backspace. As currently accepted we still have a hole to fill for coding
> styles, we do not support multi-lined string literals for code formatting
> only, nor do we have trailing precision for the same matter. (That’s what
> the backslash was meant for.) That said, I cannot break up a really long
> hardcoded string, which in my IDE is softly wrapped, into a multi-line
> string literal so that it looks in every editor the same and still expect
> the same result and be precise about the trailing whitespace characters.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 20. April 2017 um 00:27:48, Brent Royal-Gordon via swift-evolution (
> swift-evolution at swift.org) schrieb:
>
> On Apr 19, 2017, at 3:18 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Other common tools like Git already flag trailing whitespace by default,
>> so even if Swift doesn't warn about it, you might still need to satisfy
>> other tools in your pipeline.
>>
>
> Isn't that an equally good argument for Swift *not* warning you about it?
> If it's harmful, you'll have other tools in the pipeline to flag it for you.
>
>
> Cosigned. We already have an Xcode setting to strip trailing whitespace, a
> Git setting to flag it, and linter settings to remove it. (For instance,
> SwiftFormat has a --trimwhitespace flag.) Not every tool needs to handle
> every case of questionable style.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> 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/20170420/6aa93e70/attachment.html>