The multi-line string literal as it’s accepted right now only allows pretty
code generation with smaller lines. The literal itself is not reserved for
JSON, XML and similar syntaxes only, which automatically implies the existence
of conventions with longer lines. For whatever reasons a developer might have,
it’s essential to allow manual line wrapping without injecting a new line into
the resulting string. Not everyone uses the same editor width nor the same
editor with exact the same settings. You simply cannot and really should not
rely on any editor or linter for that matter, nor do I vision it as a strong
argument against having the ability to escape the new line injection. I don’t
think we should ever expect the average Swift developer sitting in-front of an
ultra wide monitor.
Consider this example:
// Currently it would look like this:
let myLongString = "Ut wisi enim ad minim veniam, quis nostrud exerci tation
ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis
autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie
consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan
et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis
dolore te feugait nulla facilisi.\n\nNam liber tempor cum soluta nobis eleifend
option congue nihil imperdiet doming id quod mazim placerat facer possim assum.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim
ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl
ut aliquip ex ea commodo consequat.\n\nDuis autem vel eum iriure dolor in
hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu
feugiat nulla facilisis."
// With the accepted version of the proposal it becomes a little bit better,
but still to long,
// because we can only replace `\n` characters with lines and that's it.
let myLongString = """
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper
suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum
iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum
dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio
dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te
feugait nulla facilisi.
Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet
doming id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet,
consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut
laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis
nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea
commodo consequat.
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse
molestie consequat, vel illum dolore eu feugiat nulla facilisis.
"""
// This is how it should ideally look like and be editor/IDE/linter
independent.
// The string produces the same result as above and does not rely on any
// soft-wrapping functionality and is written within some smaller line width.
// The trailing precision is a really good tradeoff at this point.
let myLongString = """
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper
suscipit \
lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure \
dolor in hendrerit in vulputate velit esse molestie consequat, vel illum
dolore \
eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim
qui \
blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla
facilisi.
Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet
doming \
id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet,
consectetuer \
adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore
magna \
aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci
tation \
ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse
molestie \
consequat, vel illum dolore eu feugiat nulla facilisis.
"""
The string concatenation uses optimization magic behind the scenes which is not
obvious for everyone. I personally think that every operation involved in
concatenation or any operation in-general adds a performance overhead and
theoretically needs more time to resolve the expression at runtime, which is
the natural way of thinking without any knowledge about the optimization the
compiler is able to do for you. A string literal is able to solve that issue
during compile time is simply the perfect place for that.
Some words about the trailing precision. Joe said that we could use \("") as
workaround, but if I recall correctly literals are banned from the
interpolation itself, which will result in us doing something like this:
let end = ""
let myString = """
<space><space>foo<space><space>\(end)
"""
This is a very dirty and tedious solution for that problem.
As accepted right now, no one should ever expect the result string to include
any whitespace characters at the end of each line unless there is a visible
annotation provided for precision. Providing a warning for trailing whitespace
characters would be ideal solution right now and the trailing backslash becomes
additive but not impossible to add later.
A few people already argued that the core team decided not to include a new
line at the end of each multi-line string, where you yourself said that the
absence of a trailing backslash will produce a string which always ends with a
new line. That behavior would be really strange and painful to prevent if there
is no backslash for escaping it.
The trailing backslash does not add any complexity but instead it adds more
flexibility to the literal model, which results in better readability if the
precision is desired for code formatting!
--
Adrian Zubarev
Sent with Airmail
Am 20. April 2017 um 07:30:29, Xiaodi Wu ([email protected]) schrieb:
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
<[email protected]> 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
([email protected]) schrieb:
On Apr 19, 2017, at 3:18 PM, Xiaodi Wu via swift-evolution
<[email protected]> 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
[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
