<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div>You can still have <b>union() </b>instead of or in addition to <b>adding()</b> and the API would still conform based on the following guideline:</div><div><br></div><div><ul style="box-sizing: border-box; margin: 1em 0px; padding: 0px 0px 0px 40px; list-style-position: initial; list-style-image: initial;"><li style="box-sizing: border-box; margin: 0px; padding: 0px;"><p style="box-sizing: border-box; margin: 0px 0px 1.5em; padding: 0px;"><span style="background-color: rgba(255, 255, 255, 0);">Uses of <strong style="box-sizing: border-box;">nonmutating methods should read as noun phrases</strong> when possible, e.g. <code class="highlighter-rouge" style="box-sizing: border-box; padding: 3px 8px; border: 1px solid rgb(229, 229, 229);">x.distanceTo(y)</code>, <code class="highlighter-rouge" style="box-sizing: border-box; padding: 3px 8px; border: 1px solid rgb(229, 229, 229);">i.successor()</code>.</span></p></li></ul></div><div><span style="background-color: rgba(255, 255, 255, 0);">And union is the name of the operation, in other words, it is a noun. </span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">However the mutable method would have to be <b>add()</b> which I personally like since we are adding elements to the receiver. </span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">The subtract() / subtracting() could be called remove() / removing() so that it does not sound like an arithmetic operation. </span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><br>On Feb 2, 2016, at 11:59 AM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span><br><span>on Tue Feb 02 2016, Ricardo Parada <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br><span></span><br><blockquote type="cite"><span>Hi Dave,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Let me add the following to my ideas on union(). I actually reviewed</span><br></blockquote><blockquote type="cite"><span>SetAlgebra quickly and I think it could conform to the guidelines</span><br></blockquote><blockquote type="cite"><span>better if it used the following:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>// Non-mutable methods</span><br></blockquote><blockquote type="cite"><span>let union = a.adding(b) // returns a ∪ c</span><br></blockquote><blockquote type="cite"><span>let intersection = a.intersecting(b) // returns a ∩ c</span><br></blockquote><blockquote type="cite"><span>let difference = a.subtracting(b) // returns a - b</span><br></blockquote><blockquote type="cite"><span>let xor = a.xoring(b) // returns a △ b (a.k.a. "symmetric difference"</span><br></blockquote><blockquote type="cite"><span>or "exclusive or")</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>// Mutable methods (in-place)</span><br></blockquote><blockquote type="cite"><span>a.add(b)</span><br></blockquote><blockquote type="cite"><span>a.intersect(b)</span><br></blockquote><blockquote type="cite"><span>a.subtract(b)</span><br></blockquote><blockquote type="cite"><span>a.xor(b)</span><br></blockquote><span></span><br><span>OK. You may think this is just me, but a set abstraction that doesn't</span><br><span>include an operation called "union" is really hard for me to accept.</span><br><span>It's a basic part of the set abstraction.</span><br><span></span><br><blockquote type="cite"><span>Thanks</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Feb 1, 2016, at 11:58 PM, Ricardo Parada</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:rparada@mac.com">rparada@mac.com</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Thank you Dave for your feedback and questions. I hope I can answer</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>your questions satisfactorily. See below.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Feb 1, 2016, at 7:30 PM, Dave Abrahams via swift-evolution</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:swift-evolution@swift.org">mailto:swift-evolution@swift.org</a>>></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Thanks for your review, Ricardo! Just one question below.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>on Sun Jan 31 2016, Ricardo Parada</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:swift-evolution@swift.org">mailto:swift-evolution@swift.org</a>>></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Proposal link:</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md">https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md</a></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md">https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md</a>></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>What is your evaluation of the proposal?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>+1</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I read the guidelines and I like them a lot in general. I think</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>they are a very good start.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I have read the alternatives and disagreements in the discussion</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>threads. However, in my opinion the guidelines still stand as the</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>winner. I find it better, simpler, more concise and better looking</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>than the alternatives discussed.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>For example the ed/ ing ending for non-mutable methods. This is a</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>convention I have used in java for a long time and I found it very</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>natural in general even when the English language may not cooperate as</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>it has been discussed by others. I got used to this convention very</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>quickly many years ago in libraries I use in java.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>What do you do about non-mutating versions of "split" and "union"</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>under this pattern?</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Even though the English language may not play nice with the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>guideline in these scenarios, I do not think it is a big</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>problem. Let me answer to each individually.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>split </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I think one can infer mutability by its usage on the call site. For</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>the example, if I read this code:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>x.split()</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I would infer that split() is mutating x. On the other hand if I read this:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>let y = x.split(",")</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I would infer that this split() method does not mutate x. This works</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>when reading code.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>If on the other hand I am writing the code then I would probably</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>consult the documentation and learn whether it is mutating or not.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>union </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>It would be similar for union(). Now, let's say that you want to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>have a mutable and non-mutable version of union() then we have to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>look for a different name or perhaps look at other alternatives</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>mentioned. I would consider first alternatives compatible with the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>guidelines. For example add() and adding(). If you want to stick</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>with union as the name then look for other alternatives discussed</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>such as unionInPlace() and union().</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The guidelines are not perfect but I think they are a good start. </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>There is only one guideline that I think is not aligned with the</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>consensus I seem to pick up from the discussions. That is the use of</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>camel case for enum cases. After reading different opinions I am now</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>leaning towards saying that Enum cases should be lower camel case</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>given that they are values. At first my opinion was the same as the</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>guideline. After reading the discussions and seeing examples I changed</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>my mind.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Is the problem being addressed significant enough to warrant a change to Swift?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>This will bring a lot of changes when applied. I think they are a good</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>start. I don't think it should cover all cases.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I saw the loginWithUserName(_:password:) example and alternatives:</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>login(userName:password:), etc. I don't know if this is addressed in</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>the guidelines. I don't think this example falls under the weak type</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>first argument. It would be nice to have some guidance here. I do not</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>know how to state it but I think in this case I would say</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>login(userName:password:) is better as it could be part of a family of</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>login() methods that take different parameters, i.e. credentials.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Then this is a second difference you have with the guidelines, as they</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>are currently written to discourage first argument labels in almost all</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>cases.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Thanks for pointing this out. I did not realize it until now. </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I'll have to think about this. </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Does this proposal fit well with the feel and direction of Swift?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Definitely. I find the guidelines are concise, natural and easy to get used to. </span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>If you have used other languages or libraries with a similar feature,</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>how do you feel that this proposal compares to those?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I have used Java libraries for many years that use the ed ending for</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>non-mutable methods for example.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>How much effort did you put into your review? A glance, a quick</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>reading, or an in-depth study?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I read the proposal entirely and I have read the majority of</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>responses in the mailing list.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:swift-evolution@swift.org">mailto:swift-evolution@swift.org</a>></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><<a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a>></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>-- </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>-Dave</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:swift-evolution@swift.org">mailto:swift-evolution@swift.org</a>></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><<a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a>></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><span></span><br><span>-- </span><br><span>-Dave</span><br><span></span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>