<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 Feb 18, 2016, at 11:10, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" 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 Feb 18, 2016, at 11:38 AM, 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=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">[Proposal: <a href="https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable-members-in-extensions.md%5D" class="">https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable-members-in-extensions.md]</a><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 18, 2016, at 10:29, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div 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=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><ul class=""><li class="">I'm presuming that this will not allow you to swap out one implementation for another? If not then it may be necessary to be able to call or refer to the original version of the method.</li></ul></div></div></div></div></div></blockquote></div><div class="">This is only for subclass-overriding, not ObjC-category-style method replacement.</div><div class=""><br class=""></div><div class="">Jordan</div></div></div></blockquote><br class=""></div><div class="">I hate to go all Abrahams on you, but do you have any use-cases where you're delivered a subclass and a superclass in a module, where there's no subclass implementation, and you want to add one that's an override via an extension rather than just sub-subclassing?</div></div></div></blockquote><br class=""></div><div class="">That violates the "<a href="https://blogs.msdn.microsoft.com/oldnewthing/20050607-00/?p=35413/" class="">what if two modules did this?</a>" rule. Either you own the class and you can do whatever you want to it (accepted work), or you own the method and you can override it all you want (this proposal). Anything else is unsafe (and not future-proof, if the library is part of the OS), and therefore at the very least outside the scope of this proposal.</div><div class=""><br class=""></div><div class="">(It's also harder to implement with a vtable instead of an ObjC-style method table, because the original class has all of its overrides and non-overrides listed in the constant section of its binary.)</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""></div></div></div></blockquote></div><br class=""><div class="">Going completely off into left field: Is there an ongoing discussion of module conflicts? Where there are two modules named, for example, SwiftString, and module implementation overlaps, and strategies for partial imports? Sort of "What if importing two modules does this?"</div></div></div></blockquote><br class=""></div><div>Below the module level (i.e. "assuming that module names are unique"), we've been going by the idea that nothing will conflict at the binary/symbol/runtime level as long as you don't touch Objective-C. That doesn't always reflect up happily at the source level (it's not too difficult to contrive unresolvable ambiguities with extension members), but the attitude there has been that we'll be able to dig ourselves out with language extensions that let you specify modules in various places explicitly.</div><br class=""><div class="">When ObjC enters the picture, members have to be careful of selector conflicts. That's not wonderful, but it's no worse than things were in Objective-C itself, and making 'private' things @nonobjc by default may help with some of the inadvertant conflicts people have hit in the past. Types will only conflict if explicitly renamed (classes) or marked @objc (enums).</div><div class=""><br class=""></div><div class="">But when modules themselves conflict, we're in trouble. Module name uniqueness is a pretty strong part of guaranteeing the uniqueness of everything else. You can't just rename them if there's a conflict, because they show up in, say, NSCoding archives. We've mostly just pushed the ObjC prefix problem up a level.</div><div class=""><br class=""></div><div class="">Max from the Package Manager team may have more thoughts here; over on swift-build-dev this is a very practical problem.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div></body></html>