[swift-evolution] [Pitch] Overridable Members in Extensions

[Marco Masser]

[Proposal: https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable- <https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable->members-in-extensions.md]

> On 2016-02-19, at 18:16, Jordan Rose <jordan_rose at apple.com> wrote:
> 
>> On Feb 19, 2016, at 2:23 , Marco Masser <lists at duckcode.com <mailto:lists at duckcode.com>> wrote:
>> 
>> […]
>> 
>> I hope this clears up my original answer. Either by getting the point across better, or by proving that I misinterpreted the proposal 🙃
> 
> Yes, sorry, the proposal doesn't quite do that, because of the new safety rule:
> 
> "If an extension in module B is extending a class in module A, the extension may only override members added in module B."
> 
> …by the same reasoning in my reply to Erica: allowing this would violate the "what if two modules did this? <https://blogs.msdn.microsoft.com/oldnewthing/20050607-00/?p=35413/>" rule. You know that you've broken up your plain old app into multiple modules, and that no one else is going to extend the classes you defined there, but the compiler doesn't. (And moreover, it's not as easy to add overrides after the fact with Swift as it is in Objective-C.)
> 
> This proposal is more about adding new overridable members in extensions than it is about overriding existing methods.

Ah, I think I got it now. Sorry for going off into the weeds here. I’ll give the proposal and this thread a thorough read again and think about it some more.

Thank you for taking the time to explain this!

Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160219/df938c0c/attachment.html>