<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>Would you prefer concatenation syntax using a trailing backslash over a trailing double quote?</p>
<pre><code class="swift">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."
</code></pre>
<p>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.</p>
<p>Thank you for your feedback. </p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1494959120923544832" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 16. Mai 2017 um 17:37:06, Gwendal Roué via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div></div><div>
<title></title>
<br class="">
<blockquote type="cite" class="">Le 16 mai 2017 à 16:39, David Hart
<<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> a écrit :<br class="">
<br class="">
<blockquote type="cite" class=""><br class="">
On 16 May 2017, at 15:01, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" class="">gwendal.roue@gmail.com</a>> wrote:<br class="">
<br class="">
Xiaodi Wu, your opposition has been recorded. You don't buy the
Motivation section. Other people here do, definitely.<br class="">
<br class="">
<blockquote type="cite" class="">Divorce the """ delimiter from the
multi-line syntax and have them only support unescaped
double-quotes<br class=""></blockquote>
<br class="">
This means support for:<br class="">
<br class="">
let x = "<br class="">
foo<br class="">
bar<br class="">
"<br class="">
<br class="">
This one is unexpected, and not requested by many users. Does it
bring much?<br class="">
<br class="">
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).<br class=""></blockquote>
<br class="">
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?<br class=""></blockquote>
<br class="">
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?<br class="">
<br class="">
If the two following literals are equivalent, I suggest your forget
about the first, since it brings nothing on top of
SE-0168:<br class="">
<br class="">
"<br class="">
foo<br class="">
bar<br class="">
"<br class="">
<br class="">
"""<br class="">
foo<br class="">
bar<br class="">
"""<br class="">
<br class="">
The proposal argument for it is weak:<br class="">
<br class="">
<blockquote type="cite" class="">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:<br class=""></blockquote>
<br class="">
"never" is a smelly word: real programs evolve, and good diffs are
local diffs:<br class="">
<br class="">
// bad diff<br class="">
- "<br class="">
+ """<br class="">
...<br class="">
...<br class="">
...<br class="">
- “Yes”, he said.<br class="">
+ "Yes", he said<br class="">
...<br class="">
...<br class="">
...<br class="">
-"<br class="">
+"""<br class="">
<br class="">
<blockquote type="cite" class="">Support escaping newlines in
multi-line strings with a trailing \<br class="">
<blockquote type="cite" class=""><br class="">
Great. That's the main request, unless I'm misled: split long
literals accross multiple lines. <br class="">
<br class="">
Now that Xiaodi Wu has found them, the core team questions about
the trailing backslash should be addressed in more
details.<br class=""></blockquote>
<br class="">
Sure:<br class=""></blockquote>
<br class="">
Cool. Hard-wrapping is the meat.<br class="">
<br class="">
<blockquote type="cite" class="">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.<br class="">
<br class="">
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.<br class=""></blockquote>
<br class="">
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.<br class="">
<br class="">
<blockquote type="cite" class=""><br class="">
[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.<br class="">
<br class="">
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.<br class=""></blockquote>
<br class="">
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.<br class="">
<br class="">
If you intend to provide hard-wrapping with the trailing backslash,
your proposal must support it in single-quoted literals
also.<br class="">
<br class="">
<blockquote type="cite" class=""><br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Adopt the C/Objective-C syntax
that concatenates single-line strings<br class=""></blockquote>
<br class="">
A battle-tested solution. Doesn't it look redundant with both the
"divorce" and the trailing backslash?<br class=""></blockquote>
<br class="">
It may look redundant but I see them supporting two different
purposes:<br class="">
<br class="">
<div class="">• 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.<br class=""></div>
<div class="">• 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.<br class=""></div>
<br class="">
If we did not have that feature, long text messages which need
manual wrapping would look like:<br class="">
<br class="">
assert(condition, “””<br class="">
This is my message but after some point I need to go to the
\<br class="">
next line and I need to escape newlines on every line.<br class="">
“”"<br class=""></blockquote>
<br class="">
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):<br class="">
<br class="">
<font color="#219900" class=""><font class="">// Non-wrapped
strings:</font><br class=""></font><br class="">
<span style="color: rgb(255, 72, 0);" class="">"</span>Lorem ipsum
dolor sit amet, consectetur adipiscing elit. Praesent
sed <span style="color: rgb(255, 72, 0);" class="">"</span><br class="">
<span style="color: rgb(255, 72, 0);" class="">"</span>facilisis
erat. Maecenas placerat nisi id lectus lacinia, a
vehicula <span style="color: rgb(255, 72, 0);" class="">"</span><br class="">
<span style="color: rgb(255, 72, 0);" class="">"</span>mauris
consequat.<span style="color: rgb(255, 72, 0);" class="">\n"</span><br class="">
<span style="color: rgb(255, 72, 0);" class="">"</span><span style="color: rgb(255, 72, 0);" class="">\n</span><span style="color: rgb(255, 72, 0);" class="">"</span><br class="">
<span style="color: rgb(255, 72, 0);" class="">"</span>Donec quam
arcu, venenatis a varius non, placerat a ligula. Proin
eget <span style="color: rgb(255, 72, 0);" class="">"</span><br class="">
<span style="color: rgb(255, 72, 0);" class="">"</span>libero quis
lacus sodales convallis lacinia in eros. Nulla mollis
dictum <span style="color: rgb(255, 72, 0);" class="">"</span><br class="">
<span style="color: rgb(255, 72, 0);" class="">"</span>ligula, ut
facilisis sapien sollicitudin in.<span style="color: rgb(255, 72, 0);" class="">"</span><br class="">
<br class="">
<br class="">
<span style="color: rgb(255, 72, 0);" class="">"</span><span style="color: rgb(255, 72, 0);" class="">"</span><span style="color: rgb(255, 72, 0);" class="">"</span><br class="">
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent
sed facilisis erat. Maecenas placerat nisi id lectus lacinia, a
vehicula mauris consequat.<br class="">
<br class="">
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.<br class="">
<span style="color: rgb(255, 72, 0);" class="">"</span><span style="color: rgb(255, 72, 0);" class="">"</span><span style="color: rgb(255, 72, 0);" class="">"</span><br class="">
<br class="">
<font color="#219900" class=""><font class="">// Wrapped
strings:</font><br class=""></font><br class="">
<font color="#FF4800" class="">"</font>Lorem ipsum dolor sit amet,
consectetur adipiscing elit. Praesent sed<span class="" style="color: rgb(255, 72, 0);">\n</span><span class="" style="color: rgb(255, 72, 0);">"</span><br class="">
<span class="" style="color: rgb(255, 72, 0);">"</span>facilisis
erat. Maecenas placerat nisi id lectus lacinia, a
vehicula<span class="" style="color: rgb(255, 72, 0);">\n</span><span class="" style="color: rgb(255, 72, 0);">"</span><br class="">
<span class="" style="color: rgb(255, 72, 0);">"</span>mauris
consequat.<span class="" style="color: rgb(255, 72, 0);">\n</span><span class="" style="color: rgb(255, 72, 0);">"</span><br class="">
<span class="" style="color: rgb(255, 72, 0);">"</span><span class="" style="color: rgb(255, 72, 0);">\n</span><span class="" style="color: rgb(255, 72, 0);">"</span><br class="">
<span class="" style="color: rgb(255, 72, 0);">"</span>Donec quam
arcu, venenatis a varius non, placerat a ligula. Proin
eget<span class="" style="color: rgb(255, 72, 0);">\n</span><span class="" style="color: rgb(255, 72, 0);">"</span><br class="">
<span class="" style="color: rgb(255, 72, 0);">"</span>libero quis
lacus sodales convallis lacinia in eros. Nulla mollis
dictum<span class="" style="color: rgb(255, 72, 0);">\n</span><span class="" style="color: rgb(255, 72, 0);">"</span><br class="">
<span class="" style="color: rgb(255, 72, 0);">"</span>ligula, ut
facilisis sapien sollicitudin in.<span class="" style="color: rgb(255, 72, 0);">"</span><br class="">
<br class="">
<br class="">
<span class="" style="color: rgb(255, 72, 0);">"</span><span class="" style="color: rgb(255, 72, 0);">"</span><span class="" style="color: rgb(255, 72, 0);">"</span><br class="">
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent
sed<br class="">
facilisis erat. Maecenas placerat nisi id lectus lacinia, a
vehicula<br class="">
mauris consequat.<br class="">
<br class="">
Donec quam arcu, venenatis a varius non, placerat a ligula. Proin
eget<br class="">
libero quis lacus sodales convallis lacinia in eros. Nulla mollis
dictum<br class="">
ligula, ut facilisis sapien sollicitudin in.<br class="">
<span class="" style="color: rgb(255, 72, 0);">"</span><span class="" style="color: rgb(255, 72, 0);">"</span><span class="" style="color: rgb(255, 72, 0);">"</span><br class="">
<br class="">
NB: C string concatenation has nothing to do with C's trailing
backslash:<br class="">
<br class="">
char *s = "Long strings can be bro\ <br class="">
ken into two or more pieces.";<br class="">
<br class="">
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 :-)<br class="">
<br class="">
<blockquote type="cite" class="">Le 16 mai 2017 à 16:58, Tony
Allevato <<a href="mailto:tony.allevato@gmail.com" class="">tony.allevato@gmail.com</a>> a écrit :<br class="">
<br class="">
Regarding the C/Objective-C syntax, what would be the advantages
over concatenating the strings with `+`?<br class=""></blockquote>
<br class="">
The support for ExpressibleByStringLiteral and
ExpressibleByStringInterpolation protocols.<br class="">
<br class="">
Gwendal<br class="">
<br class="">
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>