<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 6, 2017, at 2:54 PM, John McCall &lt;<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>&gt; 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=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Apr 6, 2017, at 3:05 PM, Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 6, 2017, at 1:21 PM, John McCall &lt;<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On Apr 6, 2017, at 2:12 PM, Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On Apr 6, 2017, at 1:06 PM, John McCall &lt;<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" 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;"><blockquote type="cite" class=""><div class="">On Apr 6, 2017, at 1:41 PM, Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On Apr 6, 2017, at 12:32 PM, John McCall &lt;<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" 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;"><blockquote type="cite" class=""><div class="">On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><div class=""><div class="" 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;"><blockquote type="cite" class=""><div class="">On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">The rationale for using the same syntax is that a KeyPath is an unapplied property/subscript access. Even the multi-segment part of it isn't necessarily dissimilar: I don't think it would be unreasonable to imagine that \Foo.someMethod.someOtherMethod could work*, that'd just be function composition after all.<div class=""><br class=""></div><div class="">KeyPath : Properties/Subscripts :: Functions with a self argument : Methods<br class=""><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>David</div><div class=""><br class=""></div><div class="">*not proposing this, haven't thought carefully about whether there are edge cases I'm missing here, but I think the analogy holds</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I alluded to this kind of thing in the earlier threads. &nbsp;It would be very cool to see this explored in the future.</div><div class=""><br class=""></div><div class="">I really like the latest draft and am eagerly anticipating Smart KeyPaths being implemented. &nbsp;Thank you for listening to feedback from the community!</div><div class=""><br class=""></div><div class="">One possible future direction I have been wondering about is whether it might be interesting to expose an anonymous type for each distinct key path which would have static members for getting (and setting if mutable) the value. &nbsp;The types would inherit from the most specific matching key path type included in this proposal. &nbsp;This would allow us pass key paths statically using the type system and therefore not requiring any runtime overhead. &nbsp;</div><div class=""><br class=""></div><div class="">I have experimented with this approach in some of my own code and it looks like it would be a very promising approach aside from the boilerplate required to write these types manually. &nbsp;I have abandoned this approach for now because of the boilerplate and because the syntactic sugar of the key path shorthand in this proposal is too attractive to pass up. &nbsp;I would love to explore it again in the future if key paths were to support this approach.</div></div></div></blockquote><div class=""><br class=""></div>Our generics system does not require generic code to be de-genericized ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in order to be run. &nbsp;The generic code for applying a value of an unknown key-path type would look exactly like the non-generic code for applying a dynamic key-path type. &nbsp;To get a runtime benefit, the compiler would have to de-genericize all the code between the function that formed the concrete key path and the function that applied it. &nbsp;If the compiler can do that, it can also specialize that code for a known key path argument, the same way that it can specialize a function for a known function argument. &nbsp;So there's no point.</div></div></blockquote><div class=""><br class=""></div><div class="">Thanks for the reply John. &nbsp;There may not be any additional optimization opportunities in terms of code generation when using the key path but wouldn’t it save on storage and reference counting related to key path value?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">If you're specializing all the way down, any sort of boxing should be possible to eliminate as well.</div><div class=""><br class=""></div><div class="">If you mean in unspecialized code, well, I'm not entirely sure what representation Joe is using, but I would assume that the fast path — where a key path doesn't capture anything — does not require any allocation. &nbsp;In that sense, there's a strong parallel with how we represent functions: yes, avoiding an extra allocation would be nice, but if you're willing to accept an occasional allocation in more complex cases, there are also a lot of benefits from being able to always give the type a concrete, fixed-size representation.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Key paths in this proposal are classes which require storage of the pointer as well as reference counting unless there is special of key path values. &nbsp;Is something like that planned? &nbsp;I could imagine some kind of tagged pointer might be possible but I can’t imagine how you would eliminate the need to store a word. &nbsp;It’s not that much overhead but it would still be nice to be able to avoid it when all we’re doing is passing a stateless function reference.</div></div></div></div></blockquote><div class=""><br class=""></div>Are you under the impression that run-time generics don't require passing extra pointers around?</div></div></div></blockquote><div class=""><br class=""></div><div class="">It’s quite possible there is something I don’t understand correctly. &nbsp;Let’s look at a concrete example.</div><div class=""><br class=""></div><div class="">struct UsesKeyPath {</div><div class="">&nbsp; &nbsp; let&nbsp;keyPath:&nbsp;KeyPath&lt;MyModel,&nbsp;MyValue&gt;</div><div class="">}</div><div class=""><br class=""></div><div class=""><div class="">struct UsesKeyPath&lt;T: KeyPath&lt;MyModel,&nbsp;MyValue&gt;&gt; {}</div><div class=""><br class=""></div><div class="">Is there a difference in the storage required for these two structs? &nbsp;If there isn’t then I have something to learn! :) &nbsp;I guess my assumption is that the second struct would have zero size because it has no stored properties but maybe that is incorrect.</div></div></div></div></div></blockquote><div class=""><br class=""></div>Well, these aren't equivalent, because the second doesn't actually store a key path. &nbsp;You're assuming that key paths never involve storage, which is not correct, because they can capture subscript indices. &nbsp;</div></div></blockquote><div><br class=""></div><div>The key paths necessary for the use cases I’m thinking of don’t require any state - they only represent individual properties. &nbsp;Obviously this wouldn’t work at all for key paths that require storage of subscript indices.</div><br class=""><blockquote type="cite" class=""><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="">The equivalent type would be:</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=""></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="">struct UsesKeyPath&lt;T: KeyPath&lt;MyModel, MyValue&gt;&gt; {</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="">&nbsp; let keyPath: T</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="">}</div></div></blockquote><div><br class=""></div><div>I forgot to specify the key path needs to be stateless. &nbsp;Imagining for the sake of discussion we have a protocol for that the correct example is:</div><div><br class=""></div><div>struct UsesKeyPath&lt;T: KeyPath&lt;MyModel, MyValue&gt;, StatelessKeyPath&gt; {}</div><br class=""><blockquote type="cite" class=""><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=""></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="">Now, there would be a difference in the storage required for these two structs, because presumably a value of a concrete key-path type just stores whatever data is captured for the key path, which in most cases would be nothing, and the information about what key-path it actually is would be stored in the type object for UsesKeyPath&lt;T&gt;. &nbsp;But, of course, you really do need that information in order to do anything with UsesKeyPath&lt;T&gt;, so all of the methods on it would require that type object to be passed in, which is something you can skip with the non-generic version. &nbsp;And the fact that the layout of this struct varies depending on T means that everything written in terms of it gets a lot more complicated unless specialized for a concrete key path type. &nbsp;So it would be a trade-off between the storage size of UsesKeyPath and the code-size overhead of every operation on it.</div></div></blockquote><div><br class=""></div><div>If I understand correctly the methods on my updated example would still require the type object to be passed in (when not specialized). &nbsp;On the other hand, that replaces the storage in the instance. &nbsp;</div><div><br class=""></div><div>In the use case I have these types have two key paths and are used to propagates property values from a struct to a class. &nbsp;I need one of these key path structs per property that needs to be propagated and the structs usually don’t require any additional state. &nbsp;I would like to keep them as light as possible which is why I have explored using generics rather than values. &nbsp;</div><div><br class=""></div><div>Am I incorrect in thinking that the approach of using types makes them lighter weight in terms of both storage and reference counting overhead?</div><br class=""><blockquote type="cite" 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="">Plus, of course, supporting all these key-path types would be a ton of complexity throughout the language and its implementation, because most uses of key paths cannot be type-parametric like this and so you would still need the erased KeyPath&lt;A, T&gt; type; and like I said, the dominant cases would still be just as optimizable with that erased type.</div></blockquote><div><br class=""></div><div>I agree that the erased KeyPath types are valuable and address the widest range of use cases. &nbsp;I’m not suggesting a replacement - only discussing whether this might be a worthwhile direction to explore as an a future enhancement.</div><br class=""><blockquote type="cite" 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=""></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="">John.</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=""></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=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">John.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" 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;"><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">As a secondary question, wouldn’t this be similar to the difference between generics and existentials? &nbsp;In theory the same optimizations could be applied but in practice they are not always right now. &nbsp;Is the plan to eventually put existentials on equal footing in terms of optimization?</div></div></div></blockquote><div class=""><br class=""></div>Eventually, yes, I think that's something we'd like make sure we can do.</div><div class="" 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;"><br class=""></div><div class="" 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;">John.</div><div class="" 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;"><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" 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;"><br class=""></div><div class="" 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;">John.</div><div class="" 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;"><br class=""></div><div class="" 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;"><blockquote type="cite" class=""><div class=""><div class="" 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;"><div class=""><br class=""></div><div class="">Matthew</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 5, 2017, at 5:16 PM, Patrick Smith via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">I too find the backslash odd, as it’s usually of course used to escape something.<br class=""><br class="">What about three periods?<br class=""><br class="">let firstFriendsNameKeyPath = Person...friends[0].name<br class="">print(luke[keyPath: ...friends[0].name])<br class=""><br class=""><br class="">I also find wanting to use the same syntax for unapplied methods strange, as they would product two totally different things: one a key path value, the other a function.<br class=""><br class="">Patrick<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, 6 Apr 2017 at 10:00 am, Douglas Gregor via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Apr 5, 2017, at 4:55 PM, Colin Barrett &lt;<a href="mailto:colin@springsandstruts.com" class="gmail_msg" target="_blank">colin@springsandstruts.com</a>&gt; wrote:</div><br class="m_-4532215789157486227Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">Is the choice of backslash up for review? I think another operator,<span class="Apple-converted-space">&nbsp;</span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><div class="gmail_msg">We talked through basically everything on the keyboard, and there really aren’t other options that don’t stomp on existing behavior.</div></div></div><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">perhaps backtick (`), would work better.<span class="Apple-converted-space">&nbsp;</span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><div class="gmail_msg">Backtick (`) is already taken for escaping identifiers, e.g.,&nbsp;</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><span class="m_-4532215789157486227Apple-tab-span gmail_msg" style="white-space: pre-wrap;">        </span>var `func` = { /* some code */ }</div><br class="gmail_msg"></div><div class="gmail_msg"><span class="m_-4532215789157486227Apple-tab-span gmail_msg" style="white-space: pre-wrap;">        </span>- Doug</div><div class="gmail_msg"><br class="gmail_msg"></div><br class="gmail_msg"></div>_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class="" 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;"><span class="" 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;">_______________________________________________</span><br class="" 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;"><span class="" 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;">swift-evolution mailing list</span><br class="" 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;"><a href="mailto:swift-evolution@swift.org" class="" 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;">swift-evolution@swift.org</a><br class="" 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;"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" 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;">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></blockquote></div><br class=""></body></html>