<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 Mar 2, 2016, at 9:42 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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 Mar 2, 2016, at 9:32 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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=""><br class="Apple-interchange-newline">On Mar 2, 2016, at 9:12 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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=""><br class="Apple-interchange-newline">On Mar 2, 2016, at 8:26 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@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;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2016, at 5:38 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@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;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2016, at 5:22 PM, Douglas Gregor 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 class=""><div class=""><span class="" style="font-size: 14px;"><i class="">Private conformances </i></span></div><div class=""><br class=""></div><div class="">Right now, a protocol conformance can be no less visible than the minimum of the conforming type’s access and the protocol’s access. Therefore, a public type conforming to a public protocol must provide the conformance publicly. One could imagine removing that restriction, so that one could introduce a private conformance:</div></div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><div class=""><font face="Menlo" class="">public protocol P { }</font></div><div class=""><font face="Menlo" class="">public struct X { }</font></div></div><div class=""><div class=""><font face="Menlo" class="">extension X :<span class="Apple-converted-space"> </span><b class="">internal P</b><span class="Apple-converted-space"> </span>{ … } // X conforms to P, but only within this module</font></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">The main problem with private conformances is the interaction with dynamic casting. If I have this code:</div><div class=""><br class=""></div></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><div class=""><font face="Menlo" class="">func foo(value: Any) {</font></div></div><div class=""><div class=""><font face="Menlo" class=""> if let x = value as? P { print(“P”) }</font></div></div><div class=""><div class=""><font face="Menlo" class="">}</font></div></div><div class=""><div class=""><font face="Menlo" class=""><br class=""></font></div></div><div class=""><div class=""><font face="Menlo" class="">foo(X())</font></div></div></blockquote><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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: 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;">Under what circumstances should it print “P”? If foo() is defined within the same module as the conformance of X to P? If the call is defined within the same module as the conformance of X to P? Never? Either of the first two answers requires significant complications in the dynamic casting infrastructure to take into account the module in which a particular dynamic cast occurred (the first option) or where an existential was formed (the second option), while the third answer breaks the link between the static and dynamic type systems—none of which is an acceptable result.</div></div></div></blockquote></div><br class=""><div class="">You don't need private conformances to introduce these coherence problems with dynamic casting. You only need two modules that independently extend a common type to conform to a common protocol. As Jordan discussed in his resilience manifesto, a publicly-subclassable base class that adopts a new protocol has the potential to create a conflicting conformance with external subclasses that may have already adopted that protocol.<span class="Apple-converted-space"> </span></div></div></div></blockquote><div class=""><br class=""></div><div class="">Right, multiple conformances do happen in our current model. Personally, I think that the occurrence of multiple conformances should effectively be an error at runtime unless the conformances are effectively identical (same type witnesses with the same conformances may be a reasonable approximation), and even then it’s worthy of a diagnostic as early as we can produce one, because the amount of infrastructure one needs to handle multiple conformances is significant.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">If it's a runtime error, that's a huge resilience liability, since any library adding a conformance would potentially be causing its users to start crashing at load time.</div></div></div></blockquote><div class=""><br class=""></div><div class="">My hope is that we could limit the failure mode to the case where the conflicting conformances are different in a way that affects soundness, e.g., different type witnesses for the same associated type.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I don't think we can reliably tell. As currently implemented, we generate a fresh set of witness thunks for every conformance, so the function pointers in the two modules' conformances would look different to the runtime.</div></div></div></blockquote><div><br class=""></div><div>I was thinking we only “have” to compare the type witnesses and any conformances they carry with them, because that’s what we need to ensure type soundness.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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="">I certainly agree that we’re creating both a resilience liability and a liability when composing libraries (the author of library E below did nothing wrong, but observes weird behavior), but the alternatives seem so much worse.</div></div></div></blockquote><div class=""><br class=""></div><div class="">The only place I can see where we rely on coherence is in the runtime, as you've mentioned. We're pretty good about statically maintaining conformance identity through the stack, so we ought to be able to catch static conformance mismatches in types and maybe even give reasonable error messages. It wouldn't be hard for the runtime to notice when it has a key collision in its conformance table and log a warning either—that would be consistent with what the ObjC runtime does with class or category collisions between images.</div></div></div></blockquote></div><br class=""><div class="">Right. My concern is that, in the case where we’ve lost soundness, we need to trap to avoid introducing undefined behavior. Perhaps I’m worrying overmuch.</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>