<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">-1</div><div class=""><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">* Swift is explicitly a C-family language. In most or all other C-family languages, for loop statements allow specification of conditions for exiting the loop but not for filtering. Therefore, Swift's use of `where` is unprecedented and needs to be learned anew by every user of Swift.</div></div></div></div></blockquote><br class=""></div><div class="">When was this decided? I distinctly remember some bloke under Craig Federighi’s hair saying that it was time to “move beyond” C and essentially ditch legacy conventions which no longer make sense.</div><div class=""><br class=""></div><div class="">As I understand it, Swift is a new language with new conventions. It is desirable to align as many of those as possible with existing conventions so as to be easily learned, but if you limit Swift to other languages conventions you deny it any identity. Did Python ask anybody’s opinion before dropping curly-braces? Did people learn whatever Perl is supposed to be? Look at C’s hieroglyphic for loops! </div><div class=""><br class=""></div><div class="">Realistically, “for … in … while” is not going to cause incredible confusion. Removing it would cause a lot of frustration. You can’t on the one hand say our users are comfortable with the axioms of C’s hieroglyphic loops, and on the other hand say “for x in y while" is confusing.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Again, as I said, once you've mastered something, by definition you find it not confusing. Why should we doom x% of new users to writing a loop incorrectly at least once when we don't have to?</div></div></div></div></blockquote></div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Ah, but if you’re not “doomed” to failing once, how will you ever master anything? Nobody knew how to write a C for-loop until someone showed them (and even then…). Nobody is going to just open a REPL and start writing code, with zero prior understanding of what Swift syntax looks like.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">* The word "where" does not consistently imply `break` or `continue`. In current Swift, `where` implies `break` in the context of a `while` loop and `continue` in the context of a `for` loop. Some users intuitively guess the correct meaning in each context, while others guess the wrong meaning. Therefore, the only way to learn for sure what `where` means in any context is to read the rulebook. That, by definition, means that this is unintuitive.</div></div></div></div></blockquote><br class=""></div><div class="">I didn’t even know while loops supported “where”. I can’t even imagine what that would look like, or how I would reason about one if I saw one. I Googled around a little bit and couldn’t find any examples. If they exist, sure, go ahead, get rid of them. Nobody will miss them. It definitely makes sense on ‘for’, though. Lots and lots of people will miss that; it’s a pretty well-known feature.</div><div class=""><br class=""></div><div class="">Also, after everything you said, it’s still not unintuitive. That is not how languages work at all. Languages spoken by human beings are always ambiguous to some extent, and we use context to determine which meaning is correct:</div><div class=""><br class=""></div><div class="">(Quote from <a href="https://research.googleblog.com/2016/05/announcing-syntaxnet-worlds-most.html" class="">https://research.googleblog.com/2016/05/announcing-syntaxnet-worlds-most.html</a>)</div><div class=""><blockquote type="cite" class="">One of the main problems that makes parsing so challenging is that human languages show remarkable levels of ambiguity. It is not uncommon for moderate length sentences - say 20 or 30 words in length - to have hundreds, thousands, or even tens of thousands of possible syntactic structures. A natural language parser must somehow search through all of these alternatives, and find the most plausible structure given the context. As a very simple example, the sentence "Alice drove down the street in her car" has at least two possible dependency parses:<br class=""><br class="">The first corresponds to the (correct) interpretation where Alice is driving in her car; the second corresponds to the (absurd, but possible) interpretation where the street is located in her car. The ambiguity arises because the preposition “in" can either modify drove or street; this example is an instance of what is called prepositional phrase attachment ambiguity. </blockquote></div><div class=""><br class=""></div><div class="">Even algebra is not completely unambiguous - you need to use BODMAS rules to disambiguate potential meanings.</div><div class="">It’s this context which I think you’re missing when zooming in at the word “where”:</div><div class=""><br class=""></div><div class="">- The context that this is a variation of a ‘for x in y’ loop. We know that it loops through every item in ‘y' and assigns it ‘x’. It is literally Section 2 of the 'Swift Tour' - you learn how to assign a variable, and then you learn about the “for x in y” loop. Everybody should recognise it.</div><div class="">- The context that ‘x’ is the subject, so ‘where’ is clearly a condition for x to fulfill</div><div class="">- The context that ‘where’ occurs after ‘in’, so it follows the order in which its written: ‘for every x in y, where such-and-such is true, do …”</div><div class="">- The “for x in y” loop is a data-driven loop. It doesn’t even have a loop index. It is not like a C for loop and you shouldn’t expect to reason about it that way.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">* There are other ways to break from a loop or continue to the next iteration without performance penalty. Nearly all of these serve more general purposes than a `where` clause. Some of these (such as `if` or `guard`) would already be familiar to a new user before they encounter loops, assuming a typical order for learning a programming language. Many of these (such as filtering methods on collections, or simply `if`) would be familiar to a user of another C-family language. Therefore, the `where` clause provides no independent utility, is not more discoverable than its alternatives, and is not required for progressive disclosure of an important facility to a learner (i.e. a simplified syntax for those who may not be ready for the advanced concepts needed to use a more fully-featured alternative).</div></div></div></div></blockquote><div class=""><br class=""></div>You say the points in favour of removal are not handwavey, but I’m still not convinced. “There are other ways to go to where this shortcut goes” is not reasoning. And I’d definitely argue that it is more discoverable than the ‘guard’ statement. The guard statement is stone-dead last at the end of a massive “Control-Flow” page. I would guess that most first-time readers skip those topics for later.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">The point here is that this is not a slippery slope. If `where` offered independent utility, then some confusion alone probably wouldn't be enough to justify removal, though it may justify some consideration for change. However, as the extensive discussion has shown, there is nothing `where` can do that something else can't do better. I know you like it for style, but that's not sufficient grounds for keeping something confusing, IMO.</div></div></div></div></blockquote><div class=""><br class=""></div>It’s more readable. It does that better. The tests also seem to show that (bizarrely) it’s also slightly faster than the alternatives.<br class=""><br class=""></div><div class="">Karl</div></div></div></div></div><br class=""><div><blockquote type="cite" class=""><div class="">On 10 Jun 2016, at 08:25, 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=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On Fri, Jun 10, 2016 at 12:48 AM, Brandon Knope<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:bknope@me.com" target="_blank" class="">bknope@me.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><span class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:dsa.mls@icloud.com" target="_blank" class="">dsa.mls@icloud.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><span class=""><div class=""><br class=""></div><div class="">Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> a écrit :<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">There have been, in previous threads, several examples given where users of Swift have found the behavior of `where` to be misleading and confusing.<br class=""></div></blockquote><div class=""><br class=""></div></span><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Sorry Xiaodi, but beside you (on multiple instances), and recently Erica, I have do not recall hearing that many voices saying that 'where' is confusing.</span></div></div></blockquote><div class=""><br class=""></div><div class="">Shawn Erickson wrote this to the list just yesterday:</div><div class=""><br class=""></div><div class=""><span style="font-size: 13px; white-space: pre-wrap;" class="">"I support your position on the use of where and while/when being confusing in the loop statement. I (and I know others) have for example used where in a loop statement mistakenly thinking it would terminate the loop early but of course learned that it basically filters what causes the loop body to be executed. After the fact that made sense to me but it didn't click at first."</span><br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Couldn't we find examples of anyone being confused at any syntax? Especially with an unfamiliar construct in a new language. </div><div class=""><br class=""></div><div class="">If people find the new proposed syntax confusing, do we pull that too? At what point do we stop?</div></div></blockquote><div class=""><br class=""></div><div class="">That is why I favored (1) removal of the confusing syntax altogether; and (2) this proposal, which involves aligning the confusing syntax with an existing syntax. In short, no new syntax to get confused about.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><span class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Yes, there's was maybe even less voices stating that it is not confusing, but which group is more vocal?</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Maybe I have been recently corrupt by Solid SQL queries:</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">select * from PEOPLE_TABLE where AGE_FIELD = 100</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Or by my (likely) broken English:</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">The places where I had the most fun</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">But, to me, where can only suggest some filtering (thus tag to a for .. in .., continue if not matching). </span></div></div></blockquote><div class=""><br class=""></div><div class="">I'm glad that you find it very clear. I do as well. That does not mean it is clear to everyone.</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I still have yet to see widespread confusion of this. A few people learning swift here or there, but once they learn the syntax...do they still find it confusing?</div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><div class="">I expect some concrete data on stuff like this...especially with proposed syntax changes. </div><div class=""><br class=""></div><div class="">Without concrete examples, what would stop one from coming in here and waving their hands around to push *what they like* through?</div></div></blockquote><div class=""><br class=""></div><div class="">Here's what's not handwavy:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Conclusion: the `where` clause is unprecedented, unintuitive, provides no independent utility, is not more discoverable than alternatives, and is not required for pedagogical reasons; however, it has been used incorrectly by at least some users. Therefore, it is harmful and ought to be removed or reformed.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">I know there's a linguist on the list, maybe he could comment on whether or not using 'where' as a filter is proper or an abomination.</span></div><div class=""><br class=""></div><div class="">I do not think that because something is confusing to some, or at first, that it warrant removal from the language.</div></div></blockquote><div class=""><br class=""></div><div class="">It is a very bad sign if something is confusing at first, especially to a significant proportion of users. It's true by definition that once you have mastered something you are no longer confused by it.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Again, where is this significant proportion of users? I don't mean to hound you on this, but I am genuinely curious where this is all coming from.</div></div></blockquote><div class=""><br class=""></div><div class="">We were talking about the hypothetical something here and what the bar should be for removal from the language. My response is that being confusing at first sight *is* a legitimate consideration for removal from the language. If something turns out to be a confusing way to describe a straightforward concept, then the more widespread the confusion, the more urgent its removal.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><div class="">The burden of evidence is on the proposers of these ideas. </div><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div class="">As has been stated on this list, education is a valid and important consideration for Swift. If something is confusing rather than difficult (and the *concept* of filtering a list is not at all a difficult concept), and if the same underlying concept can already be invoked in alternative and equivalent ways that are not confusing, then it's a no-brainer that the confusing thing is harmful to the language and should be removed on that basis alone.</div></div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">What is clear to one person may be confusing to another. There is no perfect syntax that will not make it confusing for some users. </div><div class=""><br class=""></div><div class="">----</div><div class=""><br class=""></div><div class="">I really think it is important to come armed with more information with these proposals. It's easy to say a significant proportion of people are confused but it would make me much more comfortable to see this data to back it up. </div><div class=""><br class=""></div><div class="">What if we are spinning our wheels for no reason on a feature that *most* don't find confusing? What if we make a bigger proportion of those who did understand it more confused now?</div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><span class=""><font color="#888888" class=""><div class=""></div><div class="">Brandon </div></font></span><div class=""><div class="h5"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">By analogy, Chinese and Japanese share difficult writing systems. Yet many people use those languages daily without difficulty. Does that mean there's not a problem? Far from it: in fact, you'll find that many intelligent people have devoted their life's work to mitigating the issue. Both Chinese and Japanese underwent a round of simplification in the 20th century. Think about it: real languages used for daily life by a significant fraction of the world's population were revamped for the purpose of increasing accessibility to new learners.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><div class="">The by-value/by-reference is well define, but can be confusing at first. Same goes for eager/lazy processing, or escaping vs non-escaping closure, or even the difference between closure and function. But no one suggest to remove them.</div></div></blockquote><div class=""><br class=""></div><div class="">Value types vs. reference types is a concept (and a moderately advanced one), eager vs. lazy processing is a concept (and a moderately advanced one), and closures are a concept (and definitely an advanced one).</div><div class=""><br class=""></div><div class="">Filtering a collection is a concept as well, and no one is suggesting its removal. We are proposing to simplify and rationalize the syntax by which filtering is invoked. If there were a way to dramatically simplify the syntax surrounding value types and reference types so as to diminish confusion, you can absolutely guarantee that there would be proposals to change the syntax. If I could think of one tomorrow, you'd see a thread tomorrow about it. I don't think I'm that smart though.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Dany</div></font></span><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class="">In fact, the first of these proposals began with a question: how does one write arbitrary Boolean assertions after a let binding? The answer (use `where`) was found to be misleading and confusing.<br class=""><br class="">I think you're being unfair to say that these proposals have no purpose other than an academic consistency.<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"> <span class="Apple-converted-space"> </span>As time goes on, I’m feeling more and more that these consistency proposals are sorely misguided. Frankly, unless the syntax is confusing or misleading, even once the developer has learned the guiding principles of Swift, consistency is not a good argument for change. This proposal is the perfect example of this. No one will find the use of “where” in loops confusing, aside from those who will wonder why it was removed from if statements. There is no misleading behavior or confusing syntax here. This is just consistency for consistency’s sake. Once this proposal is done, then another will be made to remove “where” from another place in the language. Then another and another until it’s gone completely and a very useful part of the language is removed in the name of consistency. Which really just comes down to “where” isn’t used here, so it can’t be used there anymore. It’s death by a thousand cuts.<br class=""><br class=""><br class=""><br class="">Jon Shier<br class=""><br class=""><br class="">> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">><br class="">><br class="">>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <<a href="mailto:charlie@charliemonroe.net" target="_blank" class="">charlie@charliemonroe.net</a>> wrote:<br class="">>> See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.<br class="">>><br class="">>><br class="">><br class="">> I need to correct this misapprehension.<br class="">> My suggested alternative to where was and remains `guard`.<br class="">><br class="">> -- E<br class="">><br class="">> _______________________________________________<br class="">> swift-evolution mailing list<br class="">><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></span></div></blockquote></div><br class=""></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; 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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; 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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; 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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div><br class=""></body></html>