<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>Dear Xiaodi Wu, why do you always have to be offensive in a way of questioning every single word another person says and not letting others to have their own opinion?! I do not want to have a discussion with you that will and up you asking me why is the banana crooked. I expect a focused and a constructive discussion if not mentioned otherwise.</p>
<p>My expectation from the model of the multi-lined string literal might be different from yours and you’ll have to bear with that, because I’ve got my own opinion. If you’d like me to see things differently, try to convince me instead of being unfocused and questioning every single word I’m saying. That won’t lead use to anywhere.</p>
<p>I expect the model to solve two major problems. The first one is already solved by the accepted version. The second one is the ability to escape new lines when needed (notice, I do not want to escape them all the time, but only where it’s desired). The accepted version adds more possibilities to the language and will definitely fix a lot of pain with string literals some developer had. I’m happy to see that. However from my personal standpoint, I do not write any code generators created from string literals as it was a heavily overused example in the proposal and during the discussion. I often need the ability to wrap very long strings into multiple lines for readability, but keep the result string intact. In my last response I showed a sample on how it might look like and that it’s really painful to read such a string on Git, because it does not provide any soft-wrapping like other tools might do. That is why I keep saying that the multi-line string literal should not rely on editors to solve that problem. Otherwise the bare existence of the such literal could be questioned and we could fully fall back to editor features like soft-wrapping or let the editor also wrap strings when it finds a new line character <code>\n</code> to mimic the proposed behavior. I also do not like the argument of using string concatenation to solve my particular issue, because the strings are very long and it quickly becomes were tedious. Furthermore, the multi-line string literal should not be only reserved for solving the problems you’ve mentioned. A trailing backslash does not add any complexity, and you personally don’t need that feature it does not mean that others won’t need it. It’s an additional feature which is lightweight and which won’t harm the copy-paste phenomenon most of you wanted. If you really think it adds complexity than you should also justify your thoughts to convince your conversation partner. </p>
<p>IMHO ‘complexity’ creates ‘flexibility’. If we’d only had one access modifier in Swift the model would be really simple but not flexible. Not that we have a bunch of them the model become complex but on the other hand it also become way more flexible.</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_1492765049485778944" 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 20. April 2017 um 21:50:27, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<div dir="ltr">On Thu, Apr 20, 2017 at 11:48 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_8772741926274410824bloop_markdown">
<p>The multi-line string literal as it’s accepted right now only
allows pretty code generation with smaller lines.</p>
</div>
</div>
</blockquote>
<div><br></div>
<div>This statement does not make sense to me. Multiline string
literals allow (with the unavoidable exception of some escape
sequences) code written inside the quotations marks to be exactly
as pretty as the resulting string itself. That is why it's a
literal.</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_8772741926274410824bloop_markdown">
<p>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.</p>
</div>
</div>
</blockquote>
<div><br></div>
<div>You keep re-stating instead of explaining why you think this
is essential. What are the "whatever reasons" for a developer to
need this feature? It is critical enough to be worth complicating
the design for something like literal syntax, which should be as
lightweight, straightforward, and simple as possible?</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_8772741926274410824bloop_markdown">
<p>Not everyone uses the same editor width nor the same editor with
exact the same settings.</p>
</div>
</div>
</blockquote>
<div><br></div>
<div>Do you think it is a common use case that someone will want to
have text that looks the same only to people reading the code, but
not to people reading the resulting string? Do you think someone
might want to put code inside a string literal, then wrap the
literal using 80-character lines, but write the code inside to wrap
using 120-character lines? These seem like rather implausible use
cases.</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_8772741926274410824bloop_markdown">
<p>You simply cannot and really should not rely on any editor or
linter for that matter,</p>
</div>
</div>
</blockquote>
<div><br></div>
<div>If you are going to view a Swift file, you're going to do it
through some program or other. Is it reasonable to add features to
Swift because some hypothetical text editors might not be able to
wrap lines? </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_8772741926274410824bloop_markdown">
<p>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.</p>
<p>Consider this example:</p>
<pre><code class="m_8772741926274410824swift">// 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</code></pre></div>
</div>
</blockquote>
<div><br></div>
<div>Why should one not rely on editors being able to soft wrap?
Which editors cannot soft wrap? What is wrong with soft
wrapping?</div>
<div> </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_8772741926274410824bloop_markdown">
<pre><code class="m_8772741926274410824swift"> 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.
"""
</code></pre>
<hr>
<p>The string concatenation uses optimization magic behind the
scenes which is not obvious for everyone.</p>
</div>
</div>
</blockquote>
<div><br></div>
<div>What is magic about string concatenation?</div>
<div> </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_8772741926274410824bloop_markdown">
<p>I personally think that every operation involved in
concatenation or any operation in-general adds a performance
overhead</p>
</div>
</div>
</blockquote>
<div><br></div>
<div>In what scenarios have you encountered runtime performance
bottlenecks due to concatenation of string literals?<br></div>
<div> </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_8772741926274410824bloop_markdown">
<p>and theoretically needs more time to resolve the expression at
runtime, which is the natural way of thinking without any
knowledge</p>
</div>
</div>
</blockquote>
<div><br></div>
<div>Why should we add new features simply because people who
"think without any knowledge" might have misunderstandings about
existing ones?</div>
<div> </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_8772741926274410824bloop_markdown">
<p>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.</p>
</div>
</div>
</blockquote>
<div><br></div>
<div><br></div>
<div> </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_8772741926274410824bloop_markdown">
<hr>
<p>Some words about the trailing precision. Joe said that we could
use <code>\("")</code> as workaround, but if I recall correctly
literals are banned from the interpolation itself, which will
result in us doing something like this:</p>
<pre><code class="m_8772741926274410824swift">let end = ""
let myString = """
<space><space>foo<space><<wbr>space>\(end)
"""
</code></pre>
<p>This is a very dirty and tedious solution for that problem.</p>
<p>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.</p>
</div>
</div>
</blockquote>
<div><br></div>
<div>Why shouldn't they? I expect nothing about line endings with
the current accepted design. Why should I expect literal whitespace
to be visibly annotated? I expect them to be, um, whitespace.</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_8772741926274410824bloop_markdown">
<p>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.</p>
<hr>
<p>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.</p>
<p>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!</p>
</div>
<div class="m_8772741926274410824bloop_original_html">
<div id="m_8772741926274410824bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span class=""><br></span></div>
<span class=""><br></span>
<div id="m_8772741926274410824bloop_sign_1492706130704740096" class="m_8772741926274410824bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px">
<span class="">-- <br>
Adrian Zubarev<br>
Sent with Airmail</span></div>
</div>
<span class=""><br></span>
<div>
<div class="h5">
<p class="m_8772741926274410824airmail_on">Am 20. April 2017 um
07:30:29, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>) schrieb:</p>
<blockquote type="cite" class="m_8772741926274410824clean_bq">
<div>
<div><span>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?<br>
<br></span>
<div><span>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.<br>
<br>
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.</span></div>
<div><span><br>
<br></span>
<div class="gmail_quote">
<div><span>On Wed, Apr 19, 2017 at 23:42 Adrian Zubarev via
swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>
wrote:<br></span></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_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_markdown">
<p><span>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.</span></p>
<p><span>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.</span></p>
</div>
<div class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_original_html">
</div>
</div>
<div style="word-wrap:break-word">
<div class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_original_html">
<div id="m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span><br></span></div>
<span><br></span>
<div id="m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_sign_1492662767413933056" class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px">
<span>-- <br>
Adrian Zubarev<br>
Sent with Airmail</span></div>
</div>
<span><br></span></div>
</div>
<div style="word-wrap:break-word">
<div class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_original_html">
<p class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431airmail_on">
<span>Am 20. April 2017 um 00:27:48, Brent Royal-Gordon via
swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>) schrieb:</span></p>
</div>
</div>
<div style="word-wrap:break-word">
<div class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_original_html">
<blockquote type="cite" class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431clean_bq">
<div style="word-wrap:break-word">
<div>
<div>
<blockquote type="cite">
<div><span><span>On Apr 19, 2017, at 3:18 PM, Xiaodi Wu via
swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>
wrote:</span></span></div>
<span><br class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431Apple-interchange-newline">
</span>
<div>
<blockquote class="gmail_quote" 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;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>
<div><span>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.</span></div>
</div>
</div>
</blockquote>
<div 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">
<span><br></span></div>
<div 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">
<span>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.</span></div>
</div>
</blockquote>
</div>
<div><span><br></span></div>
<div><span>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.</span></div>
<span><br></span>
<div>
<div>
<div style="font-size:12px"><span><span class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431Apple-style-span" style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
-- </span></span></div>
<div style="font-size:12px"><span class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431Apple-style-span" style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
Brent Royal-Gordon</span></div>
<div style="font-size:12px"><span class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431Apple-style-span" style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
Architechies</span></div>
</div>
</div>
<br></div>
</div>
</blockquote>
</div>
</div>
<div style="word-wrap:break-word">
<div class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_original_html">
<blockquote type="cite" class="m_8772741926274410824m_-6208984668242159980m_3629141258267239431clean_bq">
<div style="word-wrap:break-word">
<div>
<span>______________________________<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" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</span></div>
</div>
</blockquote>
</div>
</div>
______________________________<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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<div class="m_8772741926274410824bloop_markdown"></div>
</div>
</blockquote>
</div>
<br></div>
</div>
</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>