<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>The example you have provided with where you return a string happens to be short before the multi-line string starts and therefore it looks ‘okay’ at that moment. However this is the exact example which creates the most problems with the multi-line string literal model.</p>
<p>If we’re going to allow that form, that it would be natural to think one could also write like this:</p>
<pre><code class="swift">"""
Foo
Bar"""
</code></pre>
<p>But this is not correct. Furthermore the form from your example also raises the question what happens if you add a newline after the starting delimiter? Does it add a new line to the string, because at any other line it would. This creates an inconsistent behavior and overcomplicates everything?!</p>
<p>The starting delimiter should really only tell you, that the next line will be the start of your string and the indent is controlled by the closing delimiter. This is way easier. Seriously you will only need to sacrifice one line for that behavior, but the ident of your string would align perfectly.</p>
<pre><code class="swift">case .isExprSameType(let from, let to):
return """
checking a value with optional type \(from) against dynamic type \(to) \
succeeds whenever the value is non-'nil'; did you mean to use '!= nil'?\
"""
</code></pre>
<p>This eliminates all the previously mentioned issues.</p>
<hr>
<p>I strongly discourage the idea of allowing trailing whitespaces in a line which has no backslash at the end. Normal string indicates all its whitespaces visually, even if it’s hard to count them, but it does this job for you. At least you could approximately guess how many trailing whitespaces you’d have or count them with the cursor if needed.</p>
<p>The following string could have 200 characters, but you wouldn’t even notice if I don’t tell you so:</p>
<pre><code class="swift">"""
foo
"""
</code></pre>
<p>That is a really bad idea to support this. Your IDE maybe strip the whitespaces, so even if you’d want them to be there, you’ll tap into a corner where you’ll have to sacrifice that IDE feature for the whole project in order to support it for multi-line string literals in Swift. That is simply wrong.</p>
<p>I called from the beginning for trailing precision, and that’s exactly what the backslashes are meant for, plus that they disable the new line injection.</p>
<pre><code class="swift">"""
foo \
"""
</code></pre>
<p>Can you now guess how many characters this string will have? Now it’s way easier to tell.</p>
<hr>
<p>I’m not a compiler expert, but shouldn’t the tokenizer simply swallow every space characters after a backslash until it finds a new line character at the end to the current line? That’s what I would expect it to do, because otherwise you’ll end up with error messages, because you cannot rely on your IDE in that case. Notice that this is different from the trailing stripping behavior I was talking above.</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_1492039986791169024" 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 13. April 2017 um 00:20:41, Brent Royal-Gordon (<a href="mailto:brent@architechies.com">brent@architechies.com</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>
<div class="">Wow, maybe I shouldn't have slept.</div>
<div class=""><br class=""></div>
<div class="">Okay, let's deal with trailing newline first. I'm
*very* confident that trailing newlines should be kept by default.
This opinion comes from lots of practical experience with multiline
string features in other languages. In practice, if you're
generating files in a line-oriented way, you're usually generating
them a line at a time. It's pretty rare that you want to generate
half a line and then add more to it in another statement; it's more
likely you'll interpolate the data. I'm not saying it doesn't
happen, of course, but it happens a lot less often than you would
think just sitting by the fire, drinking whiskey and musing over
strings.</div>
<div class=""><br class=""></div>
<div class="">I know that, if you're pushing for this feature, it's
not satisfying to have the answer be "trust me, it's not what you
want". But trust me, it's not what you want.</div>
<div class=""><br class=""></div>
<div class="">Moving to the other end, I think we could do a
leading newline strip *if* we're willing to create multiline and
non-multiline modes—that is, newlines are _not allowed at all_
unless the opening delimiter ends its line and the closing
delimiter starts its line (modulo indentation). But I'm reluctant
to do that because, well, it's weird and complicated. I also get
the feeling that, if there's a single-line mode and a multi-line
mode, we ought to treat them as truly orthogonal features and allow
`"`-delimited strings to use multi-line mode, but I'm really not
convinced that's a good idea.</div>
<div class=""><br class=""></div>
<div class="">(Note, by the way, that heredocs—a *really* common
multiline string design—always strip the leading newline but not
the trailing one.)</div>
<div class=""><br class=""></div>
<div class="">Adrian cited this example, where I agree that you
really don't want the string to be on the same line as the leading
delimiter:</div>
<div class=""><br class=""></div>
<div class="">
<div class="">let myReallyLongXMLConstantName = """<?xml
version="1.0"?></div>
<div class="">
<catalog></div>
<div class="">
<book id="bk101" empty=""></div>
<div class="">
<author>John
Doe</author></div>
<div class="">
<title>XML
Developer's Guide</title></div>
<div class="">
<genre>Computer</genre></div>
<div class="">
<price>44.95</price></div>
<div class="">
</book></div>
<div class="">
</catalog>\</div>
<div class="">
""" </div>
<br class="Apple-interchange-newline">
But there are lots of places where it works fine. Is there a good
reason to force an additional newline in this?</div>
<div class=""><br class=""></div>
<div class="">
<div class="">case .isExprSameType(let from, let to):</div>
</div>
<div class="">
<div class="">return """checking a value with optional type \(from)
against dynamic type \(to) \</div>
<div class=""> succeeds whenever the value
is non-'nil'; did you mean to use '!= nil'?\</div>
<div class=""> """</div>
</div>
<div class=""><br class=""></div>
<div class="">I mean, we certainly could, but I'm not convinced we
should. At least, not yet.</div>
<div class=""><br class=""></div>
<div class="">In any case, trailing newline definitely stays.
Leading newline, I'm still thinking about.</div>
<div class=""><br class=""></div>
<div class="">As for other things:</div>
<div class=""><br class=""></div>
<div class="">* I see zero reason to fiddle with trailing
whitespace. If it's there, it might be significant or it might not
be. If we strip it by default and we shouldn't, the developer has
no way to protect it. Let's trust the developer. (And their
tooling—Xcode, I believe Git, and most linters already have
trailing whitespace features. We don't need them too.)</div>
<div class=""><br class=""></div>
<div class="">* Somebody asked about `"""`-delimited heredocs. I
think it's a pretty syntax, but it's not compatible with
single-line use of `"""`, and I think that's probably more
important. We can always add heredocs in another way if we decide
we want them. (I think `#to(END)` is another very Swifty syntax we
could use for heredocs--less lightweight, but it gives us a
Google-able keyword.)</div>
<div class=""><br class=""></div>
<div class="">* Literal spaces and tabs cannot be backslashed. This
is really important because, if you see a backslash after the last
visible character in a line, you can't tell just by looking whether
the next character is a space, tab, or newline. So the solution is,
if it's not a newline, it's not valid at all.</div>
<div class=""><br class=""></div>
<div class="">I'll respond to Jarod separately.</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Apr 12, 2017, at 12:07 PM, John Holdsworth
<<a href="mailto:mac@johnholdsworth.com" class="">mac@johnholdsworth.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">Finally.. a <a href="http://johnholdsworth.com/swift-LOCAL-2017-04-12-a-osx.tar.gz" class="">new Xcode toolchain</a> is available largely in sync
with the proposal as is.</div>
<div class="">(You need to restart Xcode after selecting the
toolchain to restart SourceKit)</div>
<div class=""><br class=""></div>
<div class="">I personally am undecided whether to remove the first
line if it is empty. The new</div>
<div class="">rules are more consistent but somehow less practical.
A blank initial line is almost</div>
<div class="">never what a user would want and I would tend towards
removing it automatically.</div>
<div class="">This is almost what a user would it expect it to
do.</div>
<div class=""><br class=""></div>
<div class="">I’m less sure the same applies to the trailing
newline. If this is a syntax for</div>
<div class="">multi-line strings, I'd argue that they should
normally be complete lines -</div>
<div class="">particularly since the final newline can so easily be
escaped.</div>
<div class=""><br class=""></div>
<div class=""><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class=""> </span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class="">let</span> <span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class="">longstring = ""</span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures; color: rgb(209, 47, 27);" class="">"\</span></div>
<div class="">
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> Lorem ipsum
dolor sit amet, consectetur adipiscing elit, sed do eiusmod
\</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, \</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> quis nostrud
exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat.\</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">
"</span><span style="font-variant-ligatures: no-common-ligatures;" class="">""</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class=""><br class=""></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span> <span style="font-variant-ligatures: no-common-ligatures; color: #3e1e81" class="">print</span><span style="font-variant-ligatures: no-common-ligatures" class="">(
""</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"\</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> Usage: myapp
<options></span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27); min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">
</span><br class="webkit-block-placeholder"></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> Run myapp to do
mything</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27); min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">
</span><br class="webkit-block-placeholder"></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">
Options:</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> -myoption - an
option</span></div>
<div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">
"</span><span style="font-variant-ligatures: no-common-ligatures;" class="">"" )</span></div>
</div>
<div class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""><br class=""></span></div>
<div class="">(An explicit “\n" in the string should never be
stripped btw)</div>
<div class=""><br class=""></div>
<div class="">Can we have a straw poll for the three
alternatives:</div>
<div class=""><br class=""></div>
<div class="">1) Proposal as it stands - no magic removal of
leading/training blank lines.</div>
<div class="">2) Removal of a leading blank line when indent
stripping is being applied.</div>
<div class="">3) Removal of leading blank line and trailing newline
when indent stripping is being applied.</div>
<div class=""><br class=""></div>
<div class="">My vote is for the pragmatic path: 2)</div>
<div class=""><br class=""></div>
<div class="">(The main intent of this revision was actually
removing the link between how the</div>
<div class="">string started and whether indent stripping was
applied which was unnecessary.)</div>
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 12 Apr 2017, at 17:48, Xiaodi Wu via
swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Agree. I prefer the new rules over the old, but
considering common use cases, stripping the leading and trailing
newline makes for a more pleasant experience than not stripping
either of them.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">
<br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I think that is generally worth prioritizing over a
simpler algorithm or even accommodating more styles. Moreover, a
user who wants a trailing or leading newline merely types an extra
one if there is newline stripping, so no use cases are made
difficult, only a very common one is made more
ergonomic.</span></div>
</blockquote>
</div>
<br class=""></div>
</div>
</blockquote>
</div>
<br class="">
<div class="">
<div class="">
<div style="font-size: 12px;" class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;">
-- </span></div>
<div style="font-size: 12px;" class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;">
Brent Royal-Gordon</span></div>
<div style="font-size: 12px;" class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;">
Architechies</span></div>
</div>
</div>
<br class="">
</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>