<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 Sep 30, 2016, at 5:59 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br 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=""><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="">on Fri Sep 30 2016, Douglas Gregor <</span><a href="http://dgregor-at-apple.com/" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">dgregor-AT-apple.com</a><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="">> wrote:</span><br 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 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" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class="">On Sep 30, 2016, at 1:41 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:<br class=""><br class=""><br class="">on Fri Sep 30 2016, Douglas Gregor <<a href="http://dgregor-AT-apple.com" class="">dgregor-AT-apple.com</a>> wrote:<br class=""><br class=""></blockquote></blockquote><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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">However, in cases where there is a reasonable ordering between the two<br class="">constrained extensions (i.e., one is more specialized than the other),<br class="">the less specialized constrained extension should "win" the implied<br class="">conformance.<span class="Apple-converted-space"> </span><br class=""></blockquote><br class="">“Less specialized wins” is surprising at the very least! I've only ever<br class="">seen the opposite rule (e.g. in overload resolution). What's the<br class="">rationale for this approach?<br class=""></blockquote><br class="">You need the most-general implementation so that conformance can be<br class="">used by other constrained extensions, the way the ‘Array: Equatable’<br class="">gets used by ‘Array: Hashable’ and ‘Array: Comparable’.<br class=""></blockquote><br class="">Are you sure we don't want the most specialized common ancestor of all<br class="">the constrained extensions?<br class=""></blockquote><br class="">Yes, that’s correct.<br class=""></blockquote><br 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=""><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="">We do or don't want that?</span><br 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></blockquote><div><br class=""></div><div>We want the most specialized common ancestor, i.e., the best implementation that can be used by all of the extensions that imply a conformance to Equatable.</div><br class=""><blockquote type="cite" class=""><div class=""><br 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" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Continuing the example from above:<br class=""><br class="">```swift<br class="">protocol S: R { }<br class=""><br class="">struct X5<T> { }<br class=""><br class="">extension X5: S where T: S { }<br class=""><br class="">// This last extension "wins" the implied conformance to P, because<br class="">// the extension where "T: R" is less specialized than the one<br class="">// where "T: S".<br class="">extension X5: R where T: R { }<br class="">```<br class=""><br class="">Thus, the rule for placing implied conformances is to pick the *least<br class="">specialized* extension that implies the conformance. If there is more<br class="">than one such extension, then either:<br class=""><br class="">1. All such extensions are not constrained extensions (i.e., they have<br class="">no requirements beyond what the type requires), in which case Swift<br class="">can continue to choose arbitrarily among the extensions,<span class="Apple-converted-space"> </span><br class=""></blockquote><br class="">Surely that can't be the right long-term design?<br class=""></blockquote><br class="">When all of the extensions are unconstrained, it still doesn’t matter<br class="">to the user where the conformance goes. In truth, this rule extends to<br class="">groups of extensions that have the *same* constraints—it doesn’t<br class="">matter which one we pick.<br class=""></blockquote><br class="">Seems to me it does if they define different semantics! What am I<br class="">missing?<br class=""></blockquote><br class="">If they have the same constraints, they’ll have the same<br class="">overload-resolution behavior when picking declarations to satisfy<br class="">requirements.<br class=""></blockquote><br 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=""><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="">Ya lost me here.</span><br 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></blockquote><div><br class=""></div><div>Consider this simplistic example:</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><font face="Menlo" class="">protocol P {</font></div></div><div><div><font face="Menlo" class=""> func f()</font></div></div><div><div><font face="Menlo" class="">}</font></div></div><div><div><font face="Menlo" class="">protocol Q: P { }</font></div><div><font face="Menlo" class="">protocol R: P { }</font></div><div><font face="Menlo" class=""><br class=""></font></div></div><div><div><font face="Menlo" class="">struct X { }</font></div></div><div><div><font face="Menlo" class="">extension X: P { }</font></div></div><div><div><font face="Menlo" class="">extension X {</font></div></div><div><div><font face="Menlo" class=""> func f() { … }</font></div></div><div><div><font face="Menlo" class="">}</font></div></div></blockquote><div><div><br class=""></div><div>It doesn’t actually matter whether the declaration of X’s conformance to P is placed on the first extension or on the second extension. It’ll still use that same ‘f’ to satisfy P’s requirement. This is still to if we have two conditional conformances where the extensions have the same requirements.</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><font face="Menlo" class="">struct Y<T> { }</font></div></div><div><div><font face="Menlo" class="">extension T: P where T: P { }</font></div></div><div><div><div><font face="Menlo" class="">extension T: P where T: P {</font></div></div></div><div><div><div><font face="Menlo" class=""> func f() { … }</font></div></div></div><div><div><div><font face="Menlo" class="">}</font></div></div></div></blockquote><div><br class=""><blockquote type="cite" class=""><div class=""><br 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" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">or<br class=""><br class="">2. All such extensions are constrained extensions, in which case the<br class="">program is ill-formed due to the ambiguity. The developer can<br class="">explicitly specify conformance to the protocol to disambiguate.<br class=""></blockquote><br class="">I'm really concerned about the understandability of this model. It<br class="">doesn't seem rational or consistent with other choices in the<br class="">language. Now maybe I'm missing something, but in that case I think you<br class="">haven't given a clear/precise enough description of the rules. But the<br class="">next section looks like it might clear things up for me...<br class=""><br class="">...(I'm sorry to say it didn’t)<br class=""></blockquote><br class="">While the exposition can be improved somewhat, placement of implied<br class="">conformances is fairly tricky and low-level. It will surface to the<br class="">user in cases where the user writes something like your<br class="">Comparable/Hashable example:<br class=""><br class=""><blockquote type="cite" class="">extension Array : Comparable where T : Comparable {}<br class="">extension Array : Hashable where T : Hashable {}<br class=""></blockquote><br class="">and the compiler needs to complain about the inability to place<br class="">‘Equatable’ in a way that directs the user to the correct answer<br class="">without exposing them to the entire chain of reasoning we’re going<br class="">through. The diagnostic would need some thought:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>error: ‘Array' requires an explicit conformance to ‘Equatable’<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>due to conflicting implied conformances (from ‘Comparable’ and<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>‘Hashable’)<br class=""></blockquote><br class="">If we're not making this illegal:<br class=""><br class=""> extension Foo : Comparable { ... }<br class=""> extension Foo : Hashable { ... }<br class=""> // extension Foo : Equatable { ... }<br class=""><br class="">I think it's going to be tough for people to understand why the<br class="">overlapping implied conformances are a problem in the other case.<br class=""></blockquote><br class="">Given the negative feedback we got when I tried to require this<br class="">before, I don’t think it’s wise to require it except in those cases<br class="">where it is necessary for conditional conformances. And, of course, it<br class="">would be a source-breaking change to go back and require this for<br class="">non-conditional conformances.<br class=""></blockquote><br 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=""><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 not saying we should make the above illegal! I'm saying we need a</span><br 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=""><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="">better way to explain why the conditional case doesn't work.</span><br 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></blockquote></div><br class=""><div class="">Ah; that I agree with .</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div class=""><br class=""></div></body></html>