<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 13, 2016 at 4:36 PM, let var go <span dir="ltr"><<a href="mailto:letvargo@gmail.com" target="_blank">letvargo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, Jun 13, 2016 at 12:21 PM Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 13, 2016 at 12:20 PM, let var go <span dir="ltr"><<a href="mailto:letvargo@gmail.com" target="_blank">letvargo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span><div dir="ltr">On Mon, Jun 13, 2016 at 9:46 AM Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 13, 2016 at 11:41 AM, let var go <span dir="ltr"><<a href="mailto:letvargo@gmail.com" target="_blank">letvargo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span><div dir="ltr">On Mon, Jun 13, 2016 at 9:04 AM Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">Moreover, I should add, if your goal is to eliminate the possibility of continuing and breaking from inside the loop, `.forEach()` does that exactly, so your argument would be for the elimination of `for..in` altogether.<br></div></blockquote><div><br></div></span><div>I have no "goal" of eliminating the possibility of continuing or breaking from inside the loop. In general, it is not my goal to try and control how other people code their programs at all. I don't want to tell you that you can't 'continue' if you want to 'continue.' </div><div><b><br></b></div><div><b>I am not trying to make everyone adopt my own personal coding style and/or philosophy.</b></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>We're not discussing style. </div></div></div></div></blockquote><div><br></div></span><div>Yes, we are discussing style, and for a very simple reason: Style is essential to readability and clarity.</div><div><br></div><div>When we talk about for...in...where vs. guard...continue, all we are talking about is style. In terms of functionality, they do exactly the same thing. In terms of style, however, <b>one is easier to read than the other. </b></div><div><br></div><div>Some people think that guard...continue is easier to read and understand. Others, like me, think that for...in...where is easier to read and understand. <b>But that is a disagreement over style, not functionality</b>.</div><div><br></div><div>And here is the difficult thing about debates like this: Both sides are right. What I consider to be the clearest, most readable style of coding may be confusing to someone else, and vice versa. Different people find different styles confusing. Not everyone learns the same way. Not everyone reads the same way. Not everyone codes the same way. What is hard for me to understand may be easy for you to understand.</div><div><br></div><div>So if using 'continue' inside your for...in loops makes sense to you, and it helps you understand your own code, then go for it. It's not my style, not because it is "unfashionable", but because it has the opposite effect on me - it makes the code harder for me to understand.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>You misunderstand me. I am not supporting this proposal because I think `guard` is superior style. I am supporting it because I have come to the conclusion that `where` is harmful. I do happen to think that `guard` is a superior style, but that's not the motivation for removing `where`, nor could it be a justification.</div></div></div></div></blockquote><div><br></div></span><div>No, I didn't misunderstand you. You are talking about style, even if you don't realize it. Examine these two pieces of code:</div><div><br></div><div>Example 1:</div><div>for x in xs where x < 10 {</div><div> print(x)</div><div>}</div><div><br></div><div>Example 2:</div><div>for x in xs {</div><div> guard x < 10 else { continue }</div><div> print(x)</div><div>}</div><div><br></div><div>Example 1 and Example 2 are functionally equivalent. They do exactly the same thing. They will produce exactly the same output. <b><i>They only differ with regard to style.</i></b></div><div><b><i><br></i></b></div><div>You think that Example 2 is a better style than Example 1 because you think that Example 1 is confusing to new programmers. You argue that the confusion is harmful.</div></div></div></blockquote><div><br></div><div>If you define 'style' as the difference between any two things that produce the same output, then indeed all language design is 'style.' Writing in Lisp vs. writing in C++ would be a choice of 'style.' When you say that Swift should accommodate your own 'style,' then, that could just as well be an argument for Lisp-like syntax. This is not, however, what people generally understand to be 'coding style.'</div><div><br></div><div>The fact is that there are even experienced users of Swift who see `where` and affirmatively believe it does what it does not do. The same cannot be said for `guard`. That is, a user might say, 'What in the world does guard mean?', but even a totally new user is unlikely to say, 'I can guess what guard means, and it means [something that guard does not in fact mean].' That is not at all an argument about style. And yes, I argue that confusion is harmful.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I think that Example 1 is a better style than Example 2 because I think that it is easier to read and expresses my intent with greater clarity. Whatever cognitive burden is placed on the new programmer to learn about the 'where' clause is extremely modest and more than made up for by the ability to express their intentions in a way that is both concise and readable. Example 2, by contrast, looks cluttered and splits the control-flow logic into two parts creating a cognitive burden that I consider harmful.</div></div></div></blockquote><div><br></div><div>You are stretching here; `guard` imposes a 'harmful cognitive burden'? Again, if you truly believe that, please do propose a change to the list.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>These are debates about style, and that is okay, because style is about clarity, readability, and expressiveness, all of which are essential goals. <i>Style is substance</i>. Half the battle is getting the computer to follow the correct instructions. The other half is making the code readable so that human beings can understand it - and that is a matter of style.</div><div><br></div><div>There are times where I will choose to use a 'continue' statement inside a for...in loop. The reason hardly ever has anything to do with functionality - I could design the code differently to avoid that particular code smell if I put my mind to it. No, I would choose the 'continue' statement because in that particular context it makes my code more accessible to human beings (including myself, later on). The ability to choose one solution over another for purely stylistic reasons means that I can maximize both the functionality and the readability of my code.</div><div><br></div><div>This proposal prevents the programmer from writing the best possible code because it disallows a stylistic choice that improves readability. I don't like that. It means that I have to write code that is worse than it has to be. It means that I have to write code that is uglier and more disjointed than it needs to be. That doesn't make any sense at all.</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>You made a very strong claim: use of `guard...continue` leads to 'smelly' code, or in other words bad code. In other words, you claim that `guard...continue` is harmful. That is grounds for removal, and if you believe it to be true, I encourage you to propose it to the list and get feedback on that opinion.</div><div><br></div><div>If you're saying that you simply don't prefer it for reasons of 'style,' again I emphasize that the topic at hand here is not about personal coding style. The claim we are making is that `where` is harmful. I too like it for style, and I'll be sad to see it go. But I have concluded that it must go.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>There is also a big difference between 'break' and 'continue'. I am not afraid to use 'break', and I don't consider it a code smell. It allows for early exit from a loop based on conditions that are not always known at the time the loop is entered. for...in loops are necessary precisely because they allow for the early exit.</div><div><br></div><div>You don't need for...in if you want to continue - you can use forEach for that. Instead of using 'continue', you just use 'return' without doing anything and it moves on to the next iteration. So really, the only purpose that for...in serves that is not served by forEach is early exit. But regardless, <font color="#212121" face="helvetica neue, helvetica, arial, sans-serif"><b><i>even if for...in served no additional purpose that couldn't be served by forEach, I would keep it in the language because there are situations where I believe it is easier to read, and expressiveness and clarity are important to me.</i></b></font></div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap"></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 13, 2016 at 10:55 Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 13, 2016 at 10:44 AM, let var go <span dir="ltr"><<a href="mailto:letvargo@gmail.com" target="_blank">letvargo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think we must be reading different discussions.<div><br></div><div>What I have seen in this discussion is the following:</div><div><br></div><div>a) The need to filter a for-in loop doesn't arise that often; but,</div><div>b) When it does arise, everyone who has chimed in on this thread (except the two people who are proposing the change) thinks that the "where" clause is the clearest, most expressive way to do it.</div><div><br></div><div>Something that would help me get on board with this change is more evidence about what kind of problems it is actually creating.</div><div><br></div><div>As best I can tell, this proposal got started because "somewhere" some new programmers (no one knows how many) expressed some confusion (no one knows how seriously they were confused, or how long it took them to figure it out) about how the where clause worked in a for-in loop. For all we know, once they learned the way it works, they may have said, "Hey that's cool! I'm gonna use that from now on!"</div><div><br></div><div>In other words, you seem to be talking about removing a feature that is liked by *a lot* people, based on some unsubstantiated reports of user error that may or may not have been totally unsubstantial.</div><div><br></div><div>I don't want new programmers to be confused, either, but the "where" clause is such a basic programming construct - the keyword is new, but the idea itself is as old as programming - that I don't mind expecting new programmers to learn how to use it. The learning curve should be incredibly short - it is nothing more than a filter operation.</div><div><br></div><div>There's something else here that is really important to me, though I don't know how others feel about it.</div><div><br></div><div>Using the guard...continue approach that you are promoting is a code smell. It puts control-flow logic inside the for-in loop. That is something I have always tried to avoid. I know that the language allows for it, but I believe it is bad programming practice. In fact, if you get rid of the `where` keyword, I'm still not going to use guard...continue. I'll just filter the collection first and then loop it.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This is quite the statement. It sounds like you'd be for the elimination of `continue`?</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>It is a code smell for the same reason that messing with the index inside a for;; loop was a code smell. I was always taught never to do this:</div><div><br></div><div>for var i = 0; i < array.count, i++ {</div><div> if iWantThisToLoopAnExtraTime {</div><div> i--</div><div> }</div><div>}</div><div><br></div><div>Why? Because code like that is confusing. It becomes difficult to know how many times the loop will execute, what the looping logic is, etc. Sure, I might get away with it most of the time, but it is bad practice and there is always a better way to do what you want to do. The only thing that keeps you from the better way is laziness.</div><div><br></div><div>The same is true (albeit to a lesser degree) for the guard...continue. It may not be as extreme, but it is still a code smell. It divides the control-flow logic into two parts - one outside the loop, and one inside the loop, and it suddenly becomes twice as easy to miss something.</div><div><br></div><div>Using for-in-where, all of the control-flow logic is on one single line, and once it is known that "where" operates as a filter operation, it all works together in a single, harmonious statement that declares exactly what is going to happen in a way that is totally unambiguous.</div><div><br></div><div>So by getting rid of the "where" clause, I believe that you are actually encouraging bad programming practice. Instead of encouraging the new user to learn this very simple construct that will ultimately make their code safer and more expressive without dividing their control-flow logic unnecessarily into two separate parts, you are encouraging them to just "do what they know". I think that is terrible, and you are doing them a disservice.</div><div><br></div><div>And from a personal standpoint, you are telling me that I have to write smelly code, even though there is this perfectly good non-smelly option sitting right there, because you don't want someone else to have to learn something.</div><div><div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 13, 2016 at 5:29 AM Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">I think this discussion has made it pretty plain that what is claimed to be 'so useful' is barely ever used. Moreover, it provides no independent uses. The point of these pitches is to sound out arguments, not, as far as I was aware, to take a vote.<br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 13, 2016 at 1:54 AM Jose Cheyo Jimenez <<a href="mailto:cheyo@masters3d.com" target="_blank">cheyo@masters3d.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div><span style="background-color:rgba(255,255,255,0)">--1</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">I think it would be a waste of the community's time to do a formal review when only two people are in favor of this removal. </span></div><div><br></div><div>'for in where' is so useful especially since we don't have for;;; loops anymore. I'd say leave this alone; the majority doesn't want this changed. </div></div><div dir="auto"><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><br>On Jun 10, 2016, at 10:17 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div></div><div dir="auto"><blockquote type="cite"><div><div style="white-space:pre-wrap">I think this idea--if you don't like it, then you don't have to use it--is indicative of a key worry here: it's inessential to the language and promotes dialects wherein certain people use it and others wherein they don't. This is an anti-goal.<br></div><br></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr">On Fri, Jun 10, 2016 at 12:10 let var go <<a href="mailto:letvargo@gmail.com" target="_blank">letvargo@gmail.com</a>> wrote:<br></div></div></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Leave it in!<div><br><div>It's a great little tool. I don't use it very often, but when I do it is because I've decided that in the context of that piece of code it does exactly what I want it to do with the maximum amount of clarity.</div><div><br></div></div><div>If you don't like it, then don't use it, but I can't see how it detracts from the language at all.</div><div><br></div><div>The *only* argument that I have heard for removing it is that some people don't immediately intuit how to use it. I didn't have any trouble with it at all. It follows one of the most basic programming patterns ever: "For all x in X, if predicate P is true, do something." The use of the keyword "where" makes perfect sense in that context, and when I read it out loud, it sounds natural: "For all x in X where P, do something." That is an elegant, succinct, and clear way of stating exactly what I want my program to do.</div><div><br></div><div>I don't doubt that it has caused some confusion for some people, but I'm not sold that that is a good enough reason to get rid of it. It seems strange to get rid of a tool because not everyone understands how to use it immediately, without ever having to ask a single question. As long as its not a dangerous tool (and it isn't), then keep it in the workshop for those times when it comes in handy. And even if there is some initial confusion, it doesn't sound like it lasted that long. It's more like, "Does this work like X, or does this work like Y? Let's see...oh, it works like X. Ok." That's the entire learning curve...about 5 seconds of curiosity followed by the blissful feeling of resolution.</div></div><br></blockquote></div></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div dir="ltr">On Fri, Jun 10, 2016 at 9:32 AM Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div></div></blockquote></div></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div></div></blockquote></div></blockquote></div></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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"><span>> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift Repos" folder and did the same search. Among the 15 repos in that folder, a joint search returned about 650 hits on for-in (again with some false positives) and not a single for-in-while use.<br>
<br>
</span></blockquote></div></div></div></blockquote></div></blockquote></div></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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">Weird. My own Swift projects (not on Github :P) use “where” all the time with for loops. I really like it and think it reads *and* writes far better as well as makes for nicer one-liners. In one project, by rough count, I have about 20 that use “where” vs. 40 in that same project not using “where”.<br>
<br>
In another smaller test project, there are only 10 for loops, but even so one still managed to use where.<br>
<br>
Not a lot of data without looking at even more projects, I admit, but this seems to suggest that the usage of “where” is going to be very developer-dependent. Perhaps there’s some factor of prior background at work here? (I’ve done a lot of SQL in another life, for example.)<br></blockquote></div></div></div></blockquote></div></blockquote></div></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>That is worrying if true, because it suggests that it's enabling 'dialects' of Swift, an explicit anti-goal of the language.</div></div></div></div></blockquote></div></blockquote></div></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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">
<br>
I feel like “where” is a more declarative construct and that we should be encouraging that way of thinking in general. When using it, it feels like “magic” for some reason - even though there’s nothing special about it. It feels like I’ve made the language work *for me* a little bit rather than me having to contort my solution to the will of the language. This may be highly subjective.<br>
<br>
l8r<br>
<span><font color="#888888">Sean<br>
</font></span></blockquote></div></div></div></blockquote></div></blockquote></div></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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><div>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div></div></div></blockquote></div></blockquote></div></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></blockquote></div></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></div>
</blockquote></div></div></div></div></div>
</blockquote></div></div></div></blockquote></div>
</blockquote></div></div></div></div>
</blockquote></div></div></div></blockquote></div></div></div></div>
</blockquote></div></div></div></blockquote></div></div></div></div>
</blockquote></div><br></div></div>