<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 28, 2016, at 9:51, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 27, 2016, at 5:06 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Great job thinking this all through (as usual), and I’ll be very happy to have Optional and Array become Equatable. Here’s some of my thoughts on the library evolution aspect of this:</div><div class=""><br class=""></div><div class="">- Removing a conditional conformance isn’t allowed, obviously.</div><div class="">- Adding a conditional conformance is just like adding an unconditional conformance—it needs availability info.</div></div></div></blockquote><div class=""><br class=""></div>Right. The main wrinkle I see here is that, when you add a conditional conformance, you will effectively end up with overlapping conformances when running an old application against a new library. Do you want me to capture these cases in the proposal in a section on “Resilience” or “Library Evolution”, like I’ve tried to capture the effect on ABI Stability? (I think that makes sense)</div></div></div></blockquote><div><br class=""></div><div>Sure, yes please. (I think the main point is that the "conditional" doesn't make a difference here.)</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">- It would be nice™ if making a conditional conformance more general <i class="">was</i> allowed. Since the plan doesn't allow overlapping conformances, I think this is actually implementable: just don’t put the constraints in the symbol name. I don’t know how to represent the backwards-deploying aspects of this right now, so it probably makes sense to forbid it today, but I think it would be nice if the implementation left the door open.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yeah. It’s a different set of witness tables that one would need to gather to use the conditional conformance in the newer version of the library vs. in an older version of a library. That’s okay if we leave the witness-table-gathering to the runtime, but not so great if we statically provide the witness tables.</div></div></div></div></blockquote><div><br class=""></div><div>This confuses me. Why aren't we just using the minimal (unconditional) conformance representation, and then pulling the associated type witness tables out dynamically? Is that significantly more expensive? (Am I just missing something?)</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">On that note, what happens here?</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">// Module Lib</div><div class="">public protocol Base {}</div><div class="">public protocol Sub: Base {}</div><div class="">public protocol Special: Sub {}</div><div class=""><br class=""></div><div class="">public struct Impl<T> {}</div><div class="">extension Impl: Special where T: Special {}</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">// Module Client</div><div class="">import Lib</div><div class=""><br class=""></div><div class="">extension Impl: Sub where T: Sub {}</div></blockquote><div class=""><br class=""></div>I think this gets rejected because Impl already has a conformance to Sub—the extension in Client, despite being less specialized, shows up too late to actually declare this conformance “better”. Is that correct?</div></div></blockquote><br class=""></div><div class="">Correct. Impl has a conformance to ‘Sub’ in Lib; Client cannot declare a new one, because it overlaps. Had all of this code been in one module, it would be well-formed, because the implied conformance to ’Sub’ in the first extension would lose to the explicit conformance to Sub in the second (less-specialized) extension.</div></div></div></blockquote><br class=""></div><div>Thanks!</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>