<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="">That was my impression as well, but if there's a good argument otherwise I would welcome someone eventually taking it to the proposal stage (probably after Swift 3). Even a formal discussion period followed by a rejection would help us understand if/where the type system is deficient, and perhaps figure out alternative ways to address those areas.<div class=""><div class=""><br class=""></div><div class="">Austin<br class=""><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 25, 2016, at 8:57 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div 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=""><br class=""><br class="">Sent from my iPad</div><div 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=""><br class="">On May 25, 2016, at 10:51 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" 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=""><div class=""><div class="">I think a good proposal in this space would allow protocols to specify whether they could be implemented only once or multiple times, which would address the issues the manifesto raised regarding (e.g.) multiple impls of Sequence breaking everything.</div></div></blockquote><div 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=""><br class=""></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="">I'm pretty sure the core team is strongly against allowing multiple implementations of the same protocol by the same type. This isn't the first time it has been discussed. It tends to come up in conjunction with generic protocols, but I believe all the same issues are relevant here as well.</span><div 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=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">Austin</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 25, 2016, at 8:49 PM, T.J. Usiyan <<a href="mailto:griotspeak@gmail.com" class="">griotspeak@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Yes, that is what I mean. I forgot that generic protocols were there (probably because they are listed under 'unlikely'). I have bumped into this a couple times now so I would very much like to make a type conform multiple times.<div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, May 25, 2016 at 9:46 PM, Austin Zheng<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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 class="" style="word-wrap: break-word;">Do you mean allowing a type to conform to a protocol multiple times with a different set of types each time? That's an interesting idea; the generics manifesto describes the same feature but implemented using generics: <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md</a> ("Generic Protocols").<div class=""><div class="h5"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 25, 2016, at 8:43 PM, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">+1 for the proposal.<div class=""><br class=""></div><div class="">Another quirk of associated types is that they cannot be overloaded as far as I can tell. Requiring explicit declaration could move us toward allowing multiple types to serve. Does anyone else see this as a useful feature to pursue?</div><div class="">TJ</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, May 25, 2016 at 6:33 PM, Sean Heber via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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="">This is how I feel as well - I don't understand why we'd want to make the programmer do more work. Shouldn't the goal for the compiler and language be to make the end user programmer do *less* work while still getting solid results? I would like to see more and smarter magic like inference/context awareness in the language - not less!</div><div class=""><br class=""></div><div class="">l8r</div><div class="">Sean<br class=""><br class="">Sent from my iPad</div><div class=""><div class=""><div class=""><br class="">On May 25, 2016, at 5:37 PM, Leonardo Pessoa 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 class=""><div class="" style="font-family: Calibri, sans-serif; font-size: 11pt;">-1. I don't really see how this is a bad thing and why it has to change. To me this is one of the best features of the language and I want more of it (I've been through some situations it was totally obvious the expected type of a variable and the compiler couldn't infer it) not less.<br class=""><br class=""></div></div><div dir="ltr" class=""><hr class=""><span class="" style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;">From:<span class="Apple-converted-space"> </span></span><span class="" style="font-family: Calibri, sans-serif; font-size: 11pt;"><a href="mailto:swift-evolution@swift.org" target="_blank" class="">Matthew Johnson via swift-evolution</a></span><br class=""><span class="" style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;">Sent:<span class="Apple-converted-space"> </span></span><span class="" style="font-family: Calibri, sans-serif; font-size: 11pt;">25/05/2016 07:06 PM</span><br class=""><span class="" style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;">To:<span class="Apple-converted-space"> </span></span><span class="" style="font-family: Calibri, sans-serif; font-size: 11pt;"><a href="mailto:david@hartbit.com" target="_blank" class="">David Hart</a></span><br class=""><span class="" style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;">Cc:<span class="Apple-converted-space"> </span></span><span class="" style="font-family: Calibri, sans-serif; font-size: 11pt;"><a href="mailto:swift-evolution@swift.org" target="_blank" class="">Swift-evolution</a></span><br class=""><span class="" style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;">Subject:<span class="Apple-converted-space"> </span></span><span class="" style="font-family: Calibri, sans-serif; font-size: 11pt;">Re: [swift-evolution] [Pitch] Remove associated type inference</span><br class=""><br class=""></div><div class="">I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the associated types). I think we should have a more detailed and compelling story about why we’re considering this change than I see in this proposal.</div><div class=""><br class=""></div>Are there any benefits users might receive from this change (assuming type checker architecture and bugs could eventually be ironed out)? Is it actively blocking desirable new features? If so what are they and in what way are they blocked?<div class=""><br class=""></div><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 25, 2016, at 4:43 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div class="">Here’s a pitch for removing associated type inference as per the Generics Manifesto. If we want to do it, we’d better do it before Swift 3:<div class=""><br class=""></div><div class=""><h1 class="" style="color: rgb(51, 51, 51); line-height: 1.2; padding-bottom: 0.3em; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 2.25em; margin-right: 0px; margin-bottom: 16px; margin-left: 0px; border-bottom-color: rgb(238, 238, 238); border-bottom-width: 1px; border-bottom-style: solid; background-color: rgb(255, 255, 255); margin-top: 0px !important;">Remove associated type inference</h1><ul class="" style="color: rgb(51, 51, 51); padding-left: 2em; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; margin-top: 0px; margin-bottom: 16px; background-color: rgb(255, 255, 255);"><li class="">Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/XXXX-remove-associated-type-inference.md" target="_blank" class="" style="color: rgb(64, 120, 192); text-decoration: none; background-color: transparent;">SE-XXXX</a></li><li class="">Author: <a href="https://github.com/hartbit" target="_blank" class="" style="color: rgb(64, 120, 192); text-decoration: none; background-color: transparent;">David Hart</a>, <a href="https://github.com/DougGregor" target="_blank" class="" style="color: rgb(64, 120, 192); text-decoration: none; background-color: transparent;">Douglas Gregor</a></li><li class="">Status: TBD</li><li class="">Review manager: TBD</li></ul><h2 class="" style="color: rgb(51, 51, 51); line-height: 1.225; padding-bottom: 0.3em; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 1.75em; margin-top: 1em; margin-bottom: 16px; border-bottom-color: rgb(238, 238, 238); border-bottom-width: 1px; border-bottom-style: solid; background-color: rgb(255, 255, 255);"><a href="https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#introduction" target="_blank" class="" style="color: rgb(64, 120, 192); line-height: 1; padding-right: 2px; text-decoration: none; display: inline-block; background-color: transparent;"><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Introduction</h2><p class="" style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; margin-top: 0px; margin-bottom: 16px; background-color: rgb(255, 255, 255);">This proposal seeks to remove the inference of associated types in types conforming to protocols.</p><h2 class="" style="color: rgb(51, 51, 51); line-height: 1.225; padding-bottom: 0.3em; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 1.75em; margin-top: 1em; margin-bottom: 16px; border-bottom-color: rgb(238, 238, 238); border-bottom-width: 1px; border-bottom-style: solid; background-color: rgb(255, 255, 255);"><a href="https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#motivation" target="_blank" class="" style="color: rgb(64, 120, 192); line-height: 1; padding-right: 2px; text-decoration: none; display: inline-block; background-color: transparent;"><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Motivation</h2><p class="" style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; margin-top: 0px; margin-bottom: 16px; background-color: rgb(255, 255, 255);">Even if associated types inference in a useful feature, it is also a big source of bugs in the compiler. This proposal argues that the usefulness does not outweight its architectural complexity. As per the <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md" target="_blank" class="" style="color: rgb(64, 120, 192); text-decoration: none; background-color: transparent;">Generics Manifesto</a>:</p><blockquote class="" style="margin: 0px 0px 16px; padding: 0px 15px; color: rgb(119, 119, 119); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; border-left-color: rgb(221, 221, 221); border-left-width: 4px; border-left-style: solid; background-color: rgb(255, 255, 255);"><div class="" style="margin-top: 0px; margin-bottom: 0px;">associated type inference is the only place in Swift where we have a global type inference problem: it has historically been a major source of bugs, and implementing it fully and correctly requires a drastically different architecture to the type checker.</div></blockquote><p class="" style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; margin-top: 0px; margin-bottom: 16px; background-color: rgb(255, 255, 255);">Because this is a breaking change, it would be beneficial to implement it for Swift 3. </p><h2 class="" style="color: rgb(51, 51, 51); line-height: 1.225; padding-bottom: 0.3em; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 1.75em; margin-top: 1em; margin-bottom: 16px; border-bottom-color: rgb(238, 238, 238); border-bottom-width: 1px; border-bottom-style: solid; background-color: rgb(255, 255, 255);"><a href="https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#detailed-design" target="_blank" class="" style="color: rgb(64, 120, 192); line-height: 1; padding-right: 2px; text-decoration: none; display: inline-block; background-color: transparent;"><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Detailed Design</h2><p class="" style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; margin-top: 0px; margin-bottom: 16px; background-color: rgb(255, 255, 255);">The proposal would remove associated type inference and make code which relied on it invalid:</p><div class="" style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; margin-bottom: 16px; background-color: rgb(255, 255, 255);"><pre class="" style="padding: 16px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; line-height: 1.45; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; background-color: rgb(247, 247, 247);"><span class="" style="color: rgb(167, 29, 93);">protocol</span> IteratorProtocol {
associatedtype Element
<span class="" style="color: rgb(167, 29, 93);">mutating</span> <span class="" style="color: rgb(167, 29, 93);">func</span> <span class="" style="color: rgb(121, 93, 163);">next</span>() <span class="" style="color: rgb(167, 29, 93);">-></span> Element?
}
<span class="" style="color: rgb(167, 29, 93);">struct</span> IntIterator <span class="" style="color: rgb(167, 29, 93);">:</span> IteratorProtocol {
<span class="" style="color: rgb(167, 29, 93);">mutating</span> <span class="" style="color: rgb(167, 29, 93);">func</span> <span class="" style="color: rgb(121, 93, 163);">next</span>() <span class="" style="color: rgb(167, 29, 93);">-></span> <span class="" style="color: rgb(0, 134, 179);">Int</span>? { <span class="" style="color: rgb(167, 29, 93);">...</span> } <span class="" style="color: rgb(150, 152, 150);">// used to infer Element = Int</span>
}</pre></div><p class="" style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; margin-top: 0px; margin-bottom: 16px; background-color: rgb(255, 255, 255);">The compiler would generate an error message stating: <code class="" style="margin: 0px; padding: 0.2em 0px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; background-color: rgba(0, 0, 0, 0.0392157);">error: IntIterator is missing its Element associated type declaration</code>. The code would have to be modified as follows to fix the error:</p><div class="" style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; margin-bottom: 16px; background-color: rgb(255, 255, 255);"><pre class="" style="padding: 16px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; line-height: 1.45; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; background-color: rgb(247, 247, 247);"><span class="" style="color: rgb(167, 29, 93);">struct</span> IntIterator <span class="" style="color: rgb(167, 29, 93);">:</span> IteratorProtocol {
<span class="" style="color: rgb(167, 29, 93);">typealias</span> Element <span class="" style="color: rgb(167, 29, 93);">=</span> <span class="" style="color: rgb(0, 134, 179);">Int</span>
<span class="" style="color: rgb(167, 29, 93);">mutating</span> <span class="" style="color: rgb(167, 29, 93);">func</span> <span class="" style="color: rgb(121, 93, 163);">next</span>() <span class="" style="color: rgb(167, 29, 93);">-></span> <span class="" style="color: rgb(0, 134, 179);">Int</span>? { <span class="" style="color: rgb(167, 29, 93);">return</span> <span class="" style="color: rgb(0, 134, 179);">nil</span> } <span class="" style="color: rgb(150, 152, 150);">// used to infer Element = Int</span>
}</pre></div><h2 class="" style="color: rgb(51, 51, 51); line-height: 1.225; padding-bottom: 0.3em; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 1.75em; margin-top: 1em; margin-bottom: 16px; border-bottom-color: rgb(238, 238, 238); border-bottom-width: 1px; border-bottom-style: solid; background-color: rgb(255, 255, 255);"><a href="https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#impact-on-existing-code" target="_blank" class="" style="color: rgb(64, 120, 192); line-height: 1; padding-right: 2px; text-decoration: none; display: inline-block; background-color: transparent;"><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Impact on Existing Code</h2><p class="" style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; margin-top: 0px; margin-bottom: 16px; background-color: rgb(255, 255, 255);">This is a breaking change that will require conforming types which relied on the inference, including in the Standard Library, to explicitly declare associated types. A Fix-It could be introduced to add the <code class="" style="margin: 0px; padding: 0.2em 0px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; background-color: rgba(0, 0, 0, 0.0392157);">typealias</code> and leave the type to be filled in. That way, all the type inference could be removed from the compiler.</p><h2 class="" style="color: rgb(51, 51, 51); line-height: 1.225; padding-bottom: 0.3em; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 1.75em; margin-top: 1em; margin-bottom: 16px; border-bottom-color: rgb(238, 238, 238); border-bottom-width: 1px; border-bottom-style: solid; background-color: rgb(255, 255, 255);"><a href="https://github.com/hartbit/swift-evolution/blob/remove-associated-type-inference/proposals/XXXX-remove-associated-type-inference.md#alternatives-considered" target="_blank" class="" style="color: rgb(64, 120, 192); line-height: 1; padding-right: 2px; text-decoration: none; display: inline-block; background-color: transparent;"><u class=""></u><u class=""></u></a></h2></div></div></div></blockquote></div></div></div><br class=""><div class="">[The entire original message is not included.]</div></div></blockquote></div></div><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><span class=""><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=""></span></div></blockquote></div><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=""><br class=""></blockquote></div><br class=""></div>_______________________________________________<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" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></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" class="">swift-evolution@swift.org</a></span><br class=""><span 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></div></blockquote></div><br class=""></div></div></div></div></body></html>