Would you prefer concatenation syntax using a trailing backslash over a
trailing double quote?
let s = "Long strings can be bro\
"ken into two or more pieces."
let s = "Long strings can be bro"
"ken into two or more pieces."
At least it seems reasonable and consistent to me, because this is no more a
feature for escaping new lines only, but a feature for hard wrapping string
literals.
Thank you for your feedback.
--
Adrian Zubarev
Sent with Airmail
Am 16. Mai 2017 um 17:37:06, Gwendal Roué via swift-evolution
([email protected]) schrieb:
Le 16 mai 2017 à 16:39, David Hart <[email protected]> a écrit :
On 16 May 2017, at 15:01, Gwendal Roué <[email protected]> wrote:
Xiaodi Wu, your opposition has been recorded. You don't buy the Motivation
section. Other people here do, definitely.
Divorce the """ delimiter from the multi-line syntax and have them only support
unescaped double-quotes
This means support for:
let x = "
foo
bar
"
This one is unexpected, and not requested by many users. Does it bring much?
I wonder whether this addition was introduced in order to make the proposal as
consistent as possible, and prevent some criticisms. It has proven pointless. I
suggest forgetting about pleasing people who don't want to be pleased, and to
reconsider this "divorce" section. Consistency is not the main point. The main
point is UX. This means easing the daily life of code writers, and easing the
daily life of code readers (this involves being careful which text editors and
code prettyfiers are unable to handle the proposal).
Well, one of the issues I have with the status-quo is that ""” has two meanings
(support for “ without escaping and multi-line support), which causes
consistency issues when you want to support “"” one-liners. I prefer a model
where features can be orthogonally composed: hence “”” for escaping, and
newlines around delimiters to signify multi-lines. Support for multi-lines with
“ delimiters is a natural consequence of that model: so why disallow it?
Because this pollutes your proposal. Instead of making it simpler, it makes it
more complex. You force the reader to think about the consequences of the
composition of orthogonal topics, and sort between useful ones that improve
life, and useless ones that pollute the mind, the time of stack overflow
reviewers, and the future Swift String tutorials. Do you want to give more work
to the linters and style fashionistas who love those kind of holes in language?
If the two following literals are equivalent, I suggest your forget about the
first, since it brings nothing on top of SE-0168:
"
foo
bar
"
"""
foo
bar
"""
The proposal argument for it is weak:
They gain support for " delimiters, which has the nice advantage of saving a
few characters in multi-line strings which are known to never contain
double-quotes:
"never" is a smelly word: real programs evolve, and good diffs are local diffs:
// bad diff
- "
+ """
...
...
...
- “Yes”, he said.
+ "Yes", he said
...
...
...
-"
+"""
Support escaping newlines in multi-line strings with a trailing \
Great. That's the main request, unless I'm misled: split long literals accross
multiple lines.
Now that Xiaodi Wu has found them, the core team questions about the trailing
backslash should be addressed in more details.
Sure:
Cool. Hard-wrapping is the meat.
acknowledge[] that single-line triple quoted strings have other uses in other
languages, [...] but supporting that alongside the indentation-stripping
behavior leads to a lot of subtlety, and there could be other solutions to the
escaping problem down the line, such as raw strings.
I’m not sure what subtleties they are referring to, so I don’t know how to
address those fears. And I’m not convinced raw strings are the right solution
because I’d like to retain escaping and string interpolation even in those
one-liners. Raw strings are interesting, I just don’t see them as a solution
for triple-quoted one-liners.
This is about "single-line triple quoted strings", not trailing backslash and
hard-wrapping. Still, more about that below, in the section about C inspiration.
[d]iscussion on the list raised the idea of allowing a line to end with \ to
"escape" the newline and elide it from the value of the literal.' They
deliberately rejected that feature for Swift 4, reasoning that '[they] had
concerns about only allowing that inside multi-line literals and felt that that
could also be considered later as an additive feature.
This last one confused me. In what else than multi-line literals could we
escape newlines? Be definition, if you don’t escape it, it’s a newline and your
are by definition in a multi-line literal.
This means that SE-0168 was about triple-quoted literals, and that the core
team felt uneasy supporting trailing backslash for triple-quoted literals only.
If you intend to provide hard-wrapping with the trailing backslash, your
proposal must support it in single-quoted literals also.
Adopt the C/Objective-C syntax that concatenates single-line strings
A battle-tested solution. Doesn't it look redundant with both the "divorce" and
the trailing backslash?
It may look redundant but I see them supporting two different purposes:
• Multi-line strings allow editing and copy/pasting of long strings, containing
newlines, without having to prefix each line with a delimiter (because it does
it’s nice leading whitespace stripping): it’s great for DSLs like SQL where
newlines help readability but has no effect on parsing. But it comes at the
expense of vertical space.
• The string concatenation syntax is great for shorter pieces of text where
newlines should not be inserted by default and where vertical space is more
conservative: greater for text messages.
If we did not have that feature, long text messages which need manual wrapping
would look like:
assert(condition, “””
This is my message but after some point I need to go to the \
next line and I need to escape newlines on every line.
“”"
C string concatenation is quite good for strings that are not wrapped (think
markdown), while SE-0168 literals shine for strings that are already wrapped
(think commits written by Linus):
// Non-wrapped strings:
"Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent sed "
"facilisis erat. Maecenas placerat nisi id lectus lacinia, a vehicula "
"mauris consequat.\n"
"\n"
"Donec quam arcu, venenatis a varius non, placerat a ligula. Proin eget "
"libero quis lacus sodales convallis lacinia in eros. Nulla mollis dictum "
"ligula, ut facilisis sapien sollicitudin in."
"""
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent sed facilisis
erat. Maecenas placerat nisi id lectus lacinia, a vehicula mauris consequat.
Donec quam arcu, venenatis a varius non, placerat a ligula. Proin eget libero
quis lacus sodales convallis lacinia in eros. Nulla mollis dictum ligula, ut
facilisis sapien sollicitudin in.
"""
// Wrapped strings:
"Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent sed\n"
"facilisis erat. Maecenas placerat nisi id lectus lacinia, a vehicula\n"
"mauris consequat.\n"
"\n"
"Donec quam arcu, venenatis a varius non, placerat a ligula. Proin eget\n"
"libero quis lacus sodales convallis lacinia in eros. Nulla mollis dictum\n"
"ligula, ut facilisis sapien sollicitudin in."
"""
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent sed
facilisis erat. Maecenas placerat nisi id lectus lacinia, a vehicula
mauris consequat.
Donec quam arcu, venenatis a varius non, placerat a ligula. Proin eget
libero quis lacus sodales convallis lacinia in eros. Nulla mollis dictum
ligula, ut facilisis sapien sollicitudin in.
"""
NB: C string concatenation has nothing to do with C's trailing backslash:
char *s = "Long strings can be bro\
ken into two or more pieces.";
The C's trailing backslash only means "dear parser, please pretend the
following newline does not exist." C has thus no support for indentation,
unlike Swift and SE-0168. Since the core team has rejected triple-quoted
strings that do not start with a newline because of subtleties with
indentation, the proposal needs *great care* on this topic :-)
Le 16 mai 2017 à 16:58, Tony Allevato <[email protected]> a écrit :
Regarding the C/Objective-C syntax, what would be the advantages over
concatenating the strings with `+`?
The support for ExpressibleByStringLiteral and ExpressibleByStringInterpolation
protocols.
Gwendal
_______________________________________________
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
