<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 7, 2017, at 1:43 PM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: SFHello-Regular; 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; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On 7 Sep 2017, at 19:36, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" class="">tony.allevato@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="" 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; -webkit-text-stroke-width: 0px;"><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Sep 7, 2017 at 11:18 AM Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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="" style="word-wrap: break-word;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 7 Sep 2017, at 18:53, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_-252206569380553808Apple-interchange-newline"><div class=""><div dir="ltr" class="" 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;"><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Sep 7, 2017 at 10:39 AM Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" target="_blank" class="">gwendal.roue@gmail.com</a>> 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="" style="word-wrap: break-word;"><div class=""><blockquote type="cite" class=""><div class="">Le 7 sept. 2017 à 14:45, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" target="_blank" class="">tony.allevato@gmail.com</a>> a écrit :</div><br class="m_-252206569380553808m_9067213542021244859Apple-interchange-newline"><div class=""><span class="" 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; float: none; display: inline !important;">Right, let's make sure we're talking about the right thing here. Gwendal, your issue isn't with synthesis in the form of Codable or the new additions to Equatable/Hashable which are opt-in-by-conformance, it's with the specific case of raw value enums or enums without associated values where the synthesis is implicit with no way to opt-out. That's a big difference.</span><br class="" 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;"></div></blockquote><div class=""><br class=""></div></div></div><div class="" style="word-wrap: break-word;"><div class="">Yes.</div><div class=""></div></div><div class="" style="word-wrap: break-word;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class="" 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; float: none; display: inline !important;">I can definitely see the latter being an issue if it were more widespread, and I'd be supportive of those enums being required to declare their conformance for consistency (though it would be source breaking).</span><br class="" 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;"></div></blockquote><div class=""><br class=""></div></div></div><div class="" style="word-wrap: break-word;"><div class="">Yes, unfortunately.</div></div><div class="" style="word-wrap: break-word;"><div class=""><br class=""><br class=""><blockquote type="cite" class=""><div class=""><span class="" 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; float: none; display: inline !important;">However, I still haven't seen a real issue that has come up because of the distinction being drawn here between default implementations vs. implementations that can access other parts of the concrete type. It sounds like this discussion is trying to protect against a hypothetical problem that hasn't happened yet and may not happen; it would be helpful to show some motivating real-world cases where this is indeed a severe problem.</span></div></blockquote><br class=""></div></div><div class="" style="word-wrap: break-word;"><div class=""></div><div class="">Yes. I'm not talking about implementation itself. I know this has been the main topic until I have tried to bring in the topic of the consequences of non-avoidable synthesis (extra methods that may conflict with userland methods).</div><div class=""><br class=""></div><div class="">If you ask me for a real-world case, then I think I gave one. Let me rephrase it:</div><div class=""><br class=""></div><div class="">it's impossible to define a value-backed enum without getting free Equatable conformance. This free conformance is sometimes unwanted, and I gave the example of DSLs. Now this problem is not *severe*. It's more a blind spot in the language, and finally just an unwanted side-effect of a compiler convenience,</div></div></blockquote><div class=""><br class=""></div><div class="">Again, this is not the issue that Haravikk is describing in this thread.</div><div class=""><br class=""></div><div class="">I'll clarify—your issue is specifically with the fact that enums with raw values and enums without associated values receive Equatable even without explicitly conforming to it, and therefore users have no way of opting out of it. This predates SE-0185, and I didn't propose making any changes to the conformance of those enums for source compatibility reasons, though I wouldn't be opposed to it because it makes them consistent across the board.</div><div class=""><br class=""></div><div class="">Haravikk's argument is about synthesized conformances like Codable and Equatable/Hashable in SE-0185, where the user must explicitly conform the type to those protocols. His claim is that that act of opting in is not sufficient and that it is still dangerous if those synthesized conformances can access members that are not also declared in the protocol. That's a completely separate issue to yours, and one that I hope he'll present more evidence of. Right now, requiring that you not only explicitly conform to the protocol but also explicitly request the synthesis feels like a solution without an actual problem, and is a situation we already have today with default method implementations.</div></div></div></div></blockquote><br class=""></div></div><div class="" style="word-wrap: break-word;"><div class="">The simplest real-world case is easy:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="m_-252206569380553808Apple-tab-span" style="white-space: pre-wrap;"> </span>struct Foo { var data:String }</font></div><div class=""><font face="Monaco" class=""><span class="m_-252206569380553808Apple-tab-span" style="white-space: pre-wrap;"> </span>extension Foo : Equatable {} // This currently produces an error, in future it will not</font></div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Why is this a problem? It's no different than if someone extended Foo to conform to a protocol with a default implementation that was written in code.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I'm sorry but I have now explained why it isn't multiple times; a non-reflective default conformance can<span class="Apple-converted-space"> </span><b class="">ONLY</b> act upon methods and properties that the protocol itself has defined, meaning that it knows<span class="Apple-converted-space"> </span><b class="">everything</b><span class="Apple-converted-space"> </span>it needs to know in order to do whatever it wants to do with those methods and properties<span class="Apple-converted-space"> </span><b class="">because it defined them</b>.</div></div></div></blockquote><div>Just because it might have defined the properties does not necessarily mean that those properties are sufficient context for providing a default implementation:</div><div><pre class=" language-swift" style="-webkit-print-color-adjust: exact; margin-top: 0.5em; margin-bottom: 0.5em; background-color: rgb(245, 242, 240); border: 1px solid rgb(204, 204, 204); font-size: 13px; line-height: 1.5; overflow: auto; padding: 1em; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; text-shadow: white 0px 1px; font-family: "SF Mono", Menlo, Consolas, Monaco, "Andale Mono", "Ubuntu Mono", monospace; white-space: pre-wrap; word-break: normal; word-wrap: normal; tab-size: 4; -webkit-hyphens: none;"><code class=" language-swift" style="-webkit-print-color-adjust: exact; margin: 0px; padding: 0px; border: none; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-image: none; text-shadow: white 0px 1px; font-family: "SF Mono", Menlo, Consolas, Monaco, "Andale Mono", "Ubuntu Mono", monospace; word-spacing: normal; word-break: normal; word-wrap: normal; line-height: 1.5; tab-size: 4; -webkit-hyphens: none;">protocol <span class="token builtin" style="-webkit-print-color-adjust: exact; color: rgb(102, 153, 0);">Fooable</span> <span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">:</span> <span class="token builtin" style="-webkit-print-color-adjust: exact; color: rgb(102, 153, 0);">Equatable</span> <span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">{ // Equatable is just a simple example</span>
<span class="token keyword" style="-webkit-print-color-adjust: exact; color: rgb(0, 119, 170);">var</span> myFoo<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">:</span> <span class="token builtin" style="-webkit-print-color-adjust: exact; color: rgb(102, 153, 0);">Int</span> <span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">{</span> <span class="token keyword" style="-webkit-print-color-adjust: exact; color: rgb(0, 119, 170);">get</span> <span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">}</span>
<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">}</span>
<span class="token keyword" style="-webkit-print-color-adjust: exact; color: rgb(0, 119, 170);">extension</span> <span class="token builtin" style="-webkit-print-color-adjust: exact; color: rgb(102, 153, 0);">Fooable</span> <span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">{</span>
<span class="token keyword" style="-webkit-print-color-adjust: exact; color: rgb(0, 119, 170);">static</span> <span class="token keyword" style="-webkit-print-color-adjust: exact; color: rgb(0, 119, 170);">func</span> <span class="token operator" style="-webkit-print-color-adjust: exact; color: rgb(166, 127, 89); background-color: rgba(255, 255, 255, 0.498039); background-position: initial initial; background-repeat: initial initial;">==</span><span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">(</span><span class="token number" style="-webkit-print-color-adjust: exact; color: rgb(153, 0, 85);">_</span> lhs<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">:</span> <span class="token keyword" style="-webkit-print-color-adjust: exact; color: rgb(0, 119, 170);">Self</span><span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">,</span> <span class="token number" style="-webkit-print-color-adjust: exact; color: rgb(153, 0, 85);">_</span> rhs<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">:</span> <span class="token keyword" style="-webkit-print-color-adjust: exact; color: rgb(0, 119, 170);">Self</span><span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">)</span> <span class="token operator" style="-webkit-print-color-adjust: exact; color: rgb(166, 127, 89); background-color: rgba(255, 255, 255, 0.498039); background-position: initial initial; background-repeat: initial initial;">-</span><span class="token operator" style="-webkit-print-color-adjust: exact; color: rgb(166, 127, 89); background-color: rgba(255, 255, 255, 0.498039); background-position: initial initial; background-repeat: initial initial;">></span> <span class="token builtin" style="-webkit-print-color-adjust: exact; color: rgb(102, 153, 0);">Bool</span> <span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">{</span>
<span class="token keyword" style="-webkit-print-color-adjust: exact; color: rgb(0, 119, 170);">return</span> lhs<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">.</span>myFoo <span class="token operator" style="-webkit-print-color-adjust: exact; color: rgb(166, 127, 89); background-color: rgba(255, 255, 255, 0.498039); background-position: initial initial; background-repeat: initial initial;">==</span> rhs<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">.</span>myFoo
<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">}</span>
<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">}</span>
<span class="token keyword" style="-webkit-print-color-adjust: exact; color: rgb(0, 119, 170);">struct</span> X <span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">:</span> <span class="token builtin" style="-webkit-print-color-adjust: exact; color: rgb(102, 153, 0);">Fooable</span> <span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">{</span>
<span class="token keyword" style="-webkit-print-color-adjust: exact; color: rgb(0, 119, 170);">let</span> myFoo<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">:</span> <span class="token builtin" style="-webkit-print-color-adjust: exact; color: rgb(102, 153, 0);">Int</span>
<span class="token keyword" style="-webkit-print-color-adjust: exact; color: rgb(0, 119, 170);">let</span> myName<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">:</span> <span class="token builtin" style="-webkit-print-color-adjust: exact; color: rgb(102, 153, 0);">String</span>
<span class="token comment" spellcheck="true" style="-webkit-print-color-adjust: exact; color: slategray;">// Whoops, forgot to give an implementation of ==</span>
<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">}</span>
<span class="token function" style="-webkit-print-color-adjust: exact; color: rgb(221, 74, 104);">print</span><span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">(</span><span class="token function" style="-webkit-print-color-adjust: exact; color: rgb(221, 74, 104);">X</span><span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">(</span>myFoo<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">:</span> <span class="token number" style="-webkit-print-color-adjust: exact; color: rgb(153, 0, 85);">42</span><span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">,</span> myName<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">:</span> <span class="token string" style="-webkit-print-color-adjust: exact; color: rgb(102, 153, 0);">"Alice"</span><span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">)</span> <span class="token operator" style="-webkit-print-color-adjust: exact; color: rgb(166, 127, 89); background-color: rgba(255, 255, 255, 0.498039); background-position: initial initial; background-repeat: initial initial;">==</span> <span class="token function" style="-webkit-print-color-adjust: exact; color: rgb(221, 74, 104);">X</span><span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">(</span>myFoo<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">:</span> <span class="token number" style="-webkit-print-color-adjust: exact; color: rgb(153, 0, 85);">42</span><span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">,</span> myName<span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">:</span> <span class="token string" style="-webkit-print-color-adjust: exact; color: rgb(102, 153, 0);">"Bob"</span><span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">)</span><span class="token punctuation" style="-webkit-print-color-adjust: exact; color: rgb(153, 153, 153);">)</span> <span class="token comment" spellcheck="true" style="-webkit-print-color-adjust: exact; color: slategray;">// true</span></code></pre><div class="">This property is <i class="">necessary</i>, but not <i class="">sufficient</i> to provide a correct implementation. A default implementation might be able to <i class="">assume</i> something about the types that it defines, but it does not necessarily know enough.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: SFHello-Regular; 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; -webkit-text-stroke-width: 0px;" class=""><div class="">Reflective/synthesised default implementations<span class="Apple-converted-space"> </span><b class="">must by their very nature</b> make assumptions about a concrete type that are<span class="Apple-converted-space"> </span><b class="">not</b><span class="Apple-converted-space"> </span>cannot be guaranteed to be correct. The properties and methods they may end up interacting with<span class="Apple-converted-space"> </span><b class="">may have nothing at all to do with the protocol</b>. Equatable remains by far the simplest example; just because a developer has used equatable properties does<span class="Apple-converted-space"> </span><b class="">not</b> guarantee that all of them should be compared during a check for equality.</div></div></div></blockquote><div>In the same way that you might consider synthesized conformances to overreach into a type and touch things which are not related to a protocol, default implementations can be considered <i class="">underreach</i> in that they don’t know anything about properties which are necessary for providing a correct implementation.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: SFHello-Regular; 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; -webkit-text-stroke-width: 0px;" class=""><div class="">These things are two very different beasts.</div></div></div></blockquote>I think they’re very much two sides of the same coin.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: SFHello-Regular; 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; -webkit-text-stroke-width: 0px;" class=""><div class="">While a developer may wish to override a default implementation, it should only be to provide optimisations that a protocol cannot; e.g- providing a logarithmic time search to replace to a linear time search. The end result however should be the same; i.e- there is no change in behaviour, only detail.</div><div class=""><br class=""></div><div class="">A synthesised/reflective implementation however may return a result that is simply incorrect, because it is based on assumptions made by the protocol developer, with no input from the developer of the concrete type. In this case the developer must override it in to provide<span class="Apple-converted-space"> </span><b class="">correct</b> behaviour.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class="" 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; -webkit-text-stroke-width: 0px;"><div class="gmail_quote"><div class="">That's not a fair characterization. Just because your concerns were disagreed with does not mean they were ignored; my understanding is that the core team views these synthesized conformances as a different kind of default method (and one which could be hoisted out of the compiler once sufficient metaprogramming facilities are available).</div><div class=""><br class=""></div><div class="">The way to handle synthesized conformances was discussed during the review period for Codable, during the earlier pitch a few months ago for what became SE-0185, and again during its formal review. It's not accurate to reduce the argument you disagree with to "but Codable does it" when what you're referring to is established precedent based on those prior discussions.</div></div></div></blockquote><div class=""><br class=""></div><div class="">If that is the case then surely someone, including members of the core team, could have easily summarised what the rationale behind that was and why they think it applies to Equatable/Hashable. They did not, hence, ignored. I even framed my argument purely on the basis of why the Equatable/Hashable case differs from Codable and still nothing. It is absolutely fair for me to characterise that as being ignored.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class="" 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; -webkit-text-stroke-width: 0px;"><div class="gmail_quote"><div class="">I feel like we keep going back to this, but this statement applies equally to non-synthesized default implementations. Are you suggesting that users should have to opt-in specifically to all default implementations provided by a protocol in some way beyond merely conforming to that protocol? If not, what specifically makes synthesized conformances a special case?</div></div></div></blockquote><br class=""></div><div style="font-family: SFHello-Regular; 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; -webkit-text-stroke-width: 0px;" class="">As mentioned, this is a special case because the behaviour being provided is<span class="Apple-converted-space"> </span><b class="">not</b><span class="Apple-converted-space"> </span>constrained to the protocol that provides it; it is invasive of a concrete type, and by its very nature can potentially produce incorrect results.</div><span style="font-family: SFHello-Regular; 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; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: SFHello-Regular; 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; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: SFHello-Regular; 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; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: SFHello-Regular; 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; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: SFHello-Regular; 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: SFHello-Regular; 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; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: SFHello-Regular; 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>