<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On 28 Sep 2016, at 19:45, Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 28, 2016, at 11:40 AM, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" class="">panajev@gmail.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 iPhone</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 28 Sep 2016, at 17:51, Douglas Gregor 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><div 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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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 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="">- It would be nice™ if making a conditional conformance more general<span class="Apple-converted-space"> </span><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 class=""><br class=""></div></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><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="">Would this be a case in which the win by having this feature and letting the runtime gather the witness tables offset the losses from doing his operations at runtime? I would like to think that in cases like this there is at least the option to opt for more flexibility.</div></div></blockquote></div><div class=""><br class=""></div>I’m sure we can find a reasonable solution to this that doesn’t incur a significant runtime penalty, e.g., by teaching the runtime conformance specialization machinery to handle a “redirecting” specialization that maps from the requirements of the older (more specialized) version to the requirements of the newer (less specialized) version.<br class=""><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div class=""><br class=""></div></div></blockquote><br><div>Very glad to hear that Doug :).</div></body></html>