<div style="white-space:pre-wrap">Those aren't two "interchangeable" types in your example; it's the same type with two aliases. By contrast, the tuple types `(x: Int, y: Int)` and `(a: Int, b: Int)` are distinct, as I illustrated above.<br><br>You are correct that one of the unique aspects of labeled tuple types would no longer be so unique if Swift had implicit protocol conformance. It does not follow that this unique aspect of tuples should be eliminated from the language.<br><br>I choose to use tuples precisely where I want this behavior. For instance, I don't care if you write `typealias GridCoordinates = (x: Int, y: Int)` and I write `typealias CartesianCoordinates = ...`; I choose to alias a tuple type precisely because I want such "interchangeability." But I do care about the labels being `x` and `y`, and that's where the labeled tuple comes in.<br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 2, 2016 at 1:52 AM James Froggatt <<a href="mailto:james.froggatt@me.com">james.froggatt@me.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>typealias Point = (x: Int, y: Int)</div><div>typealias Dimensions = (x: Int, y: Int)</div><div><br></div><div>let point: Point = (x: 5, y: 5)</div><div><br></div><div>let dimensions = point</div><div><br></div><div>Fundamentally different concepts may have labels happen to be the same. Structs protect against this conversion, tuples don't.</div><div><br></div><div>Explicit protocol conformance is justified in this way:</div><div><br></div><div>protocol GridPoint {</div><div> var x: Int {get}</div><div> var y: Int {get}</div><div>}</div><div><br></div><div>protocol Box {</div><div> associatedtype UnitType</div><div> var x: UnitType {get}</div><div> var y: UnitType {get}</div><div> var z: UnitType {get}</div><div>}</div><div><br></div><div>GridPoints obviously shouldn't be Boxes, but with implicit conformance, every Box would be a GridPoint.</div><div><br>From James F</div></div><div dir="auto"><div><br>On 2 Jul 2016, at 07:31, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Sat, Jul 2, 2016 at 1:03 AM, James Froggatt <span dir="ltr"><<a href="mailto:james.froggatt@me.com" target="_blank">james.froggatt@me.com</a>></span> wrote:<br><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"><div>Tuples are inherently interchangable. If you want to avoid this, the safest way is to use a struct.</div></div></blockquote><div><br></div><div>```<br></div><div><div>typealias Foo = (a: Int, b: Int)</div><div>typealias Bar = (c: Int, d: Int)</div><div>var foo: Foo = (1, 2)</div><div>var bar: Bar = (3, 4)</div><div>foo = bar</div></div><div>```</div><div>ERROR at line 5, col 7: cannot assign value of type 'Bar' (aka '(c: Int, d: Int)') to type 'Foo' (aka '(a: Int, b: Int)')<br></div><div><br></div><div>What do you mean when you say that tuples are inherently interchangeable? What am I not safe from?</div><div><br></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"><div><br></div><div>Labels/naming shouldn't be relied on to provide type information,</div></div></blockquote><div><br></div><div>For a tuple type, labels are treated as part of the type; I *do* rely on that. Why do you say that it shouldn't be relied on?</div><div> </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"><div>this is why implicit conformance to protocols is disallowed.</div></div></blockquote><div><br></div><div>I don't follow.</div><div><br></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"><div>From James F</div><div><div><div><br>On 2 Jul 2016, at 06:43, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>What's the basis for your claim that tuples are best passed around without their labels? If I have `typealias CartesianCoordinates = (x: Double, y: Double)`, these labels are absolutely meaningful, and I would not want them to be interchangeable with a hypothetical `typealias PolarCoordinates = (r: Double, theta: Double)`. Although argument labels are part of the name, tuple labels are part of the type; there are good reasons for that, and the two are no longer meant to be similar. This proposal takes us the rest of the way in clarifying this important distinction.<br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 1, 2016 at 11:52 PM James Froggatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></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"><div><blockquote type="cite"><font color="#000000"><span style="background-color:rgba(255,255,255,0)">A parameter list of (inout Int, @noescape Int -> ()) is just a ‘tuple + annotations’ relevant to use in parameter lists. If you can restrict this pseudo-type to the appropriate context, like we are heading towards with disallowing ImplicityUnwrappedOptional in function signatures, why not restrict certain type annotations to only occur in function signatures?</span></font></blockquote><div><br></div></div></div><div dir="auto"><div>Effectively the presence of parameter annotations in a tuple make it a ‘splat-only tuple’.<br><br>From James F</div></div><div dir="auto"><div><br>On 2 Jul 2016, at 05:38, James Froggatt <<a href="mailto:james.froggatt@me.com" target="_blank">james.froggatt@me.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div><br></div><div>On 2 Jul 2016, at 05:03, Austin Zheng <<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><blockquote type="cite"><div>On Jul 1, 2016, at 8:55 PM, James Froggatt <<a href="mailto:james.froggatt@me.com" target="_blank">james.froggatt@me.com</a>> wrote:</div><br><div><div dir="auto"><div><br></div><div>On 2 Jul 2016, at 04:46, Austin Zheng <<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><div><br></div><div>This functionality naturally falls out of any decent proposal for variadic generics. I'd rather wait until we can re-add it in a principled manner than stuff yet another @-prefixed special case into the language.</div><br></div></div></blockquote><div><br></div><div>Fair point, but it seems this could stand as a lightweight complement to generics. There seems to be a lack of support for the side of keeping what functionality we already have in this area.</div></div></div></blockquote><div><br></div><div>FWIW, I liked and used tuple splat before it was removed from the language.</div><div><br></div><div>I thought about it, and I think a lightweight, limited form of tuple application would probably be worth pursuing even before variadic generics go into the language (especially since they are a low-priority item). Perhaps someone could draft a proposal for Swift 3.1.</div><br></div></div></blockquote><div><br></div><div>This is why I support keeping what existing semantics we can, rather than stripping it all out only to reimplement it as soon as people realise it's missing.</div><div><br></div><div>The distinction between (Int, Int) and ((Int, Int)) seems trivial.</div><div><br></div><div>A parameter list of (inout Int, @noescape Int -> ()) is just a ‘tuple + annotations’ relevant to use in parameter lists. If you can restrict this pseudo-type to the appropriate context, like we are heading towards with disallowing ImplicityUnwrappedOptional in function signatures, why not restrict certain type annotations to only occur in function signatures?</div><br><blockquote type="cite"><div><div><blockquote type="cite"><div><div dir="auto"><br><blockquote type="cite"><div><div><blockquote type="cite"><div><div dir="auto"><br><blockquote type="cite"><div><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Is it though? Couldn't the current confusing situation of tuple labels in the type system be changed in the exact same way?</span><br></blockquote><span></span><br><span>Tuple labels work the way you expect them to work: you can't assign an `(a: 1, b: 2)` to a variable of type `(x: Int, y: Int)`. There is nothing confusing about them, at least not in the same way that function types are.</span><br><span></span><br></div></blockquote><div><br></div><div>This seems just the same problem as not being able to assign:</div><div><br></div><div>(a: Int, b: Int) -> ()</div><div><br></div><div>to a type of:</div><div><br></div><div>(x: Int, y: Int) -> ()</div><div><br></div><div>Functions and tuples are the only uses of labels in the type system I'm aware of. The reasoning for one case seems likely to apply to the other.</div></div></div></blockquote><div><br></div><div>There was a better argument for this sort of thing before the naming guidelines. Swift 2 argument labels often described the semantic value of their arguments. Now you have guidelines which assign non-descriptive prepositional phrases as argument labels. It makes no sense to pull the prepositional phase comprising the argument label (as opposed to the argument name itself) into the type, since that phrase is meaningless outside the context of the primary function name, but the current system (and any based off it) would do just that.</div><div><br></div><div>So no, I don't think the reasoning for tuple labels applies to function argument labels.</div><br></div></div></blockquote><div><br></div><div>Sorry, I meant the reasoning for removing them from the type system. As you said, there was a better argument. I'm observing that this may once again be the case following this change.</div></div></div></blockquote></div><div><br></div><div>I still think it would be a bit odd to have (e.g.) a rejuvenated tuple splatter try to enforce the labels on whatever tuples you pass to it, since those labels would necessarily be tied to a specific function's name, rather than the meaning of the arguments themselves. Do you think there would be too much room for programmer error if such a splatter necessarily took in unlabeled tuples? (Right now any labeled tuple is interchangeable with a non-labeled tuple with the same constituent types...)</div><div><br></div></div></blockquote><div><br></div><div>My idea is that if we switch to using:</div><div><br></div><div>let functionType(a:b:) = add(_:_:)</div><div><br></div><div>then it make sense to have tuples match this syntax, to avoid having two similar naming mechanisms with very different semantics:</div><div><br></div><div>let values(x:y:) = (1, 2)</div><div><br></div><div>Like a function's argument labels are rarely sensible out of context, tuples are best passed around without considering their labels. For example:</div><div><br></div><div>let name: (first: String, last: String) = …</div><div><br></div><div>name.first //clear</div><div><br></div><div>func join(stringTuple: (String, String))</div><div><br></div><div>join(stringTuple: name) //is this allowed?</div><div><br></div><div><br></div><div>At this point (generally as soon as the tuple leaves the context of its containing variable), the original parameter labels are meaningless. Alternatively:</div><div><br></div><div><br></div><div>let name(first:last:): (String, String) = …</div><div><br></div><div>name.first //still clear</div><div><br></div><div>join(name) //clearly allowed, since the labels are not part of the type</div><div><br></div><div><br></div><div>With this, if I understand you properly, argument names wouldn't be present in the type system to begin with, so calling the result of a splatter would be predictable:</div><div><br></div><div>join(a: String, b: String)</div><div><br></div><div>let splatted: ((String, String)) -> () = splat(join) // or splat( join(a:b:) )</div><div><br></div><div>splatted(name) // or splatted( name(first:last:) )</div><br><blockquote type="cite"><div><div><blockquote type="cite"><div><div dir="auto"><div><br></div><div>It doesn't help that this went through to the wrong thread, and the quick email I sent to acknowledge this has fallen in a hole somewhere.</div><br><blockquote type="cite"><div><div><blockquote type="cite"><div><div dir="auto"><br><blockquote type="cite"><div><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Or are tuples destined to become nothing more than a historical artifact? If this is the case, then we might as well remove them now.</span><br></blockquote><span></span><br><span>Tuples have many, many uses apart from modeling argument lists.</span><br><span></span><br></div></blockquote><div><br></div><div>• lightweight structs</div><div>• loosely-typed structs</div><div>• …as structs</div><div><br></div><div>There is no particular reason Void must be modelled as the empty struct, since any non-subclassable Type.self is likewise a singleton.</div><div><br></div><div>So there's nothing really making a compelling argument here.</div></div></div></blockquote><div><br></div><div>What? You asked if tuples were going to become a historical artifact? The answer is, "no, they aren't, because they have uses besides modeling argument labels". Void as the empty tuple is irrelevant to the discussion.</div><br></div></div></blockquote><div><br></div><div>I'm not sure how to interpret this, sorry.</div></div></div></blockquote><div><br></div><div>Perhaps I misunderstood your original point. In that case, I apologize.</div><br><blockquote type="cite"><div><div dir="auto"><br><blockquote type="cite"><div><div><blockquote type="cite"><div><div dir="auto"><br><blockquote type="cite"><div><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>------------ Begin Message ------------ </span><br></blockquote><blockquote type="cite"><span>Group: gmane.comp.lang.swift.evolution </span><br></blockquote><blockquote type="cite"><span>MsgID: <<a href="mailto:CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com" target="_blank">CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com</a>> </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution <</span><br></blockquote><blockquote type="cite"><span><a href="mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org" target="_blank">swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Hello Swift community,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The review of "SE-0111: Remove type system significance of function</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>argument labels" begins now and runs through July 4. The proposal is</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>available here:</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><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Reviews are an important part of the Swift evolution process. All reviews</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>should be sent to the swift-evolution mailing list at</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>or, if you would like to keep your feedback private, directly to the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>review manager.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>What goes into a review?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The goal of the review process is to improve the proposal under review</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>through constructive criticism and contribute to the direction of Swift.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>When writing your review, here are some questions you might want to answer</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>in your review:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>* What is your evaluation of the proposal?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>+1. I'm in agreement with others in this thread who say that the labels are</span><br></blockquote><blockquote type="cite"><span>parts of the *name* of the function, not parts of its *type*. If I</span><br></blockquote><blockquote type="cite"><span>understand the other discussions regarding the evolution of Swift's</span><br></blockquote><blockquote type="cite"><span>function arguments model, the similarity to tuples with labeled components</span><br></blockquote><blockquote type="cite"><span>is a historical artifact and now merely coincidental.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The analogy to Objective-C here is obvious, where you have selectors</span><br></blockquote><blockquote type="cite"><span>instead of functions. The selector is the "name" of the "function" and it</span><br></blockquote><blockquote type="cite"><span>contains all of the parts, not just the base name.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Swift function names to me are like German separable verbs. Even when</span><br></blockquote><blockquote type="cite"><span>they're split across the sentence with multiple words in-between, the</span><br></blockquote><blockquote type="cite"><span>prefix is still considered part of that verb, not a separate word/concept.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>* Is the problem being addressed significant enough to warrant a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>change to Swift?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Yes.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>* Does this proposal fit well with the feel and direction of Swift?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Yes. This feels like a natural follow-up to SE-0021, which allowed the use</span><br></blockquote><blockquote type="cite"><span>of argument names to differentiate between overloads with the same argument</span><br></blockquote><blockquote type="cite"><span>types at the same positions. To me, this is another admission that the</span><br></blockquote><blockquote type="cite"><span>labels are part of the function's *name*.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>* If you have used other languages or libraries with a similar</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>feature, how do you feel that this proposal compares to those?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Aside from Objective-C mentioned above, the other languages I've used that</span><br></blockquote><blockquote type="cite"><span>have named/keyword arguments (like Python) are dynamic languages that treat</span><br></blockquote><blockquote type="cite"><span>the incoming argument list as a dictionary; in that case, the language</span><br></blockquote><blockquote type="cite"><span>design is significantly different and I can't draw an analogy between them.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><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 type="cite"><blockquote type="cite"><span>reading, or an in-depth study?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Read the proposal and loosely followed the discussion.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>More information about the Swift evolution process is available at</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://github.com/apple/swift-evolution/blob/master/process.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Thank you,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>-Chris Lattner</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Review Manager</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>_______________________________________________</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org" target="_blank">swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>------------- End Message ------------- </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>From James F</span><br></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" target="_blank">swift-evolution@swift.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><span></span><br></div></blockquote></div></div></blockquote></div><br></div></blockquote></div></div></blockquote></div><br></div></blockquote></div></blockquote></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>
</blockquote></div>
</div></blockquote></div></div></div></blockquote></div><br></div></div>
</div></blockquote></div></blockquote></div>