<div dir="ltr">On Thu, Apr 27, 2017 at 8:05 AM, Adrian Zubarev <span dir="ltr"><<a href="mailto:adrian.zubarev@devandartist.com" target="_blank">adrian.zubarev@devandartist.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="m_5563774932470941277bloop_markdown"><p>That is correct, however you can interpret this in two ways. You just covered the first way. The second one is, that the feature was rejected from the main proposal because it seemed inconsistent if it would *only* apply to multi-line strings.</p></div></div></blockquote><div><br></div><div>One thing I really appreciate about the core team is how carefully and clearly they express their thinking. It is unambiguous that inconsistency was one of the reasons the feature was removed from the proposal, but it was not the only reason. It doesn't say, "The core team had concerns...and _therefore_ felt that that could be considered later...." It says, "The core team had concerns...and felt that that could _also_ be considered later...." So, to recap:</div><div><br></div><div>* The feature has been considered once, and the decision is not to accept it.</div><div>* Usually, this means that the decision is not to be revisited, but the core team says that the feature can be considered again, _later_.</div><div>* If a new design is proposed for the feature (_later_), it needs to address concerns about inconsistency.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="m_5563774932470941277bloop_markdown"><p>The discussion after the accepted proposal has showed us that the feature for the backslash could be extended further to cover all string literals, not only the tripled one.</p>
<p>I think it’s worth pushing this forward. :)</p>
<p></p></div><div class="m_5563774932470941277bloop_original_html"><span class=""><div id="m_5563774932470941277bloop_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="m_5563774932470941277bloop_sign_1493298032001785088" class="m_5563774932470941277bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br></span><div><div class="h5"><p class="m_5563774932470941277airmail_on">Am 27. April 2017 um 00:40:59, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="m_5563774932470941277clean_bq"><span><div><div></div><div>
<div dir="ltr">So, independent of whether one thinks this is a good
idea or not, the core team wrote the following:
<div><br></div>
<div>> <span style="font-size:12.800000190734863px">Discussion 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; the core team had concerns
about only allowing that inside multi-line literals and felt that
that could also be considered later as an additive
feature.</span></div>
<div><span style="font-size:12.800000190734863px"><br></span></div>
<div><span style="font-size:12.800000190734863px">It seems to me
that, when the core team considers a feature and then removes it
from an accepted proposal, saying that it should be considered
_later_, that word doesn't mean immediately asking the community to
consider it again.</span></div>
<div><span style="font-size:12.800000190734863px"><br></span></div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Apr 26, 2017 at 2:14 PM, Adrian
Zubarev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">
<div class="m_5563774932470941277gmail-m_-2039866567013217785bloop_markdown">
<p>Hello folks,</p>
<p>To keep things focused I opened up a new thread for this talk.
Previously the discussion took place at the thread named
<code>[Accepted] SE-0168: Multi-Line String Literals</code>.</p>
<p>John Holdsworth has provided a first draft in his PR: <a href="https://github.com/apple/swift-evolution/pull/695" target="_blank">https://github.com/apple/swift<wbr>-evolution/pull/695</a></p>
<p>I think we need to fine tune the proposal before it gets into
the review process.</p>
<hr>
<p>To quickly sum up, the previous proposal added support for
multi-line string literals into Swift, where its model was squeezed
to the minimum.</p>
<ol>
<li>
<p>No text directly after/before the starting/closing tripled
<code>"""</code> delimiters.</p>
</li>
<li>
<p>The string content line before the closing delimiter does not
inject a new line to the final string, only lines before the last
content line does.</p>
</li>
<li>
<p>Trailing spaces in each string content lines will produce a
warning and hopefully provide a Fix-it to remove these, therefore
there is no trailing precision added with the minimum model of the
multi-line string literal. (This approach is editor/linter
independent whatsoever.)</p>
</li>
</ol>
<hr>
<p>This follow up proposal will fix the last missing peace for
multi-line string literals and additionally add new possibilities
to the single quoted string literal as well.</p>
<p>This proposal should also not change the fact number two from
above!</p>
<pre><code class="m_5563774932470941277gmail-m_-2039866567013217785swift">let s1 = """
myStringExample
"""
let s2 = "myStringExample"
s1 == s2 // => true
</code></pre>
<hr>
<p>Currently both string literals suffers from the following issue
where long strings will produce a very hard to read literal.
Notice, we don’t want to discuss here if we should or should not
ever hardcode long string literals at all.</p>
<pre><code class="m_5563774932470941277gmail-m_-2039866567013217785swift">let myLongStringWithParagraphs = """
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
"""
let myLongLineString = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat."
</code></pre>
<p>The current proposal solves that problem while also adding
trailing precision for the tripled multi-line string literal and
providing flexibility for code formatting for us developers in a
editor independent fashion.</p>
<p>The example from above could be rewritten, while preserving the
indent and producing the exact equivalent result strings as
above.</p>
<pre><code class="m_5563774932470941277gmail-m_-2039866567013217785swift">let myLongStringWithParagraphs = """
Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
sed do eiusmod tempor incididunt ut labore et dolore magna \
aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
ullamco laboris nisi ut aliquip ex ea commodo consequat.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
sed do eiusmod tempor incididunt ut labore et dolore magna \
aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
ullamco laboris nisi ut aliquip ex ea commodo consequat.
"""
let myLongLineString = "Lorem ipsum dolor sit amet, \
"consectetur adipiscing elit, sed do eiusmod tempor \
"incididunt ut labore et dolore magna aliqua. Ut enim \
"ad minim veniam, quis nostrud exercitation ullamco \
"laboris nisi ut aliquip ex ea commodo consequat."
</code></pre>
<p>If this proposal will be accepted the trailing whitespaces
inside a string literal will produce two different warnings with
similar Fix-its.</p>
<pre><code class="m_5563774932470941277gmail-m_-2039866567013217785swift">// In the examples v1 and v2 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\` after the last whitespace character.
let v1 = """
123<space>
"""
let v2 = """
abc
123<space>
"""
// In the example v3 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\n\` after the last whitespace
// character.
let v4 = """
abc<space>
123
"""
</code></pre></div>
<div class="m_5563774932470941277gmail-m_-2039866567013217785bloop_original_html">
<div id="m_5563774932470941277gmail-m_-2039866567013217785bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<span class="m_5563774932470941277gmail-HOEnZb"><font color="#888888"><br></font></span></div>
<span class="m_5563774932470941277gmail-HOEnZb"><font color="#888888"><br></font></span>
<div id="m_5563774932470941277gmail-m_-2039866567013217785bloop_sign_1493232058239898880" class="m_5563774932470941277gmail-m_-2039866567013217785bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px">
<span class="m_5563774932470941277gmail-HOEnZb"><font color="#888888">-- <br>
Adrian Zubarev<br>
Sent with Airmail</font></span></div>
</div>
</div>
<div class="m_5563774932470941277gmail-m_-2039866567013217785bloop_markdown"></div>
</div>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote>
</div>
<br></div>
</div>
</div>
</div></div></span></blockquote></div></div></div><div class="m_5563774932470941277bloop_markdown"><p></p></div></div></blockquote></div><br></div></div>