<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=""><div class="">[Proposal: <a href="https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable-members-in-extensions.md" target="_blank" class="">https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable-members-in-extensions.md</a>]</div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 18, 2016, at 5:13 , Andrew Bennett <<a href="mailto:cacoyi@gmail.com" class="">cacoyi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Sounds interesting, I know I've wanted to do similar, and had some weird bugs.<div class=""><br class=""></div><div class="">Many of my concerns have been discussed already, I've added a few more below:<br class=""><div class=""><br class=""></div><div class="">I'm also a little concerned about the potential for unexpected side-effects from methods called by the original class, *this* seems to break the principle of "<span style="font-size:13px" class="">least astonishment</span>", you're less likely to know the base classes implementation than that of your extension.<div class=""><br class=""></div><div class="">Other points worth considering:</div></div></div></div></div></blockquote><div><br class=""></div>Good questions! I'll answer them here but also update the document later today.</div><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><ul class=""><li class="">Can methods be marked as final, or something else if it's unsafe to override?</li></ul></div></div></div></div></div></blockquote><div class="">Yep, `final` should work just like it does today.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><ul class=""><li class="">What about methods marked as inline, called by the super-class, is this unexpected?</li></ul></div></div></div></div></div></blockquote><div class="">Inlining is discussed in great depth in the <a href="http://jrose-apple.github.io/swift-library-evolution/" class="">Library Evolution doc</a>, but the relevant points are that marking something inlineable doesn't guarantee it'll be inlined, and that you can't inline a call unless you know the dynamic type of the receiver (and therefore know which override will be called).</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><ul class=""><li class=""><i class="">If</i> most people only want this for testing should it only be allowed on classes imported with <span style="color:rgb(84,84,84)" class="">@</span><span style="font-weight:bold;color:rgb(106,106,106)" class="">testable </span>(only restrict this with (unsafe) ObjC classes?).</li></ul></div></div></div></div></div></blockquote><div class="">I know of at least one non-testing use case that I probably can't share, so let's just say I don't think we need to artificially limit the feature. (It's at least no <i class="">worse</i> than Objective-C.)</div><div class=""><br class=""></div><div class="">What we could do is say that methods in extensions of classes you don't own are @nonobjc by default, and that you have to opt into making them @objc. What do you think?</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><ul class=""><li class="">You probably want to swap/replace the implementation rather than just override it for testing.</li></ul></div></div></div></div></div></blockquote><div class="">That's out of scope for this proposal. If you're interested in this, I'd suggest coming up with a version of 'dynamic' that works for all Swift methods, not just @objc ones, and then further annotating that as "but only for testing".</div><div class=""><br class=""></div><br 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>This is only for subclass-overriding, not ObjC-category-style method replacement.</div><div><br class=""></div><div>Jordan</div></body></html>