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

[Greg Parker]

> On Feb 10, 2016, at 7:57 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
>> On Feb 10, 2016, at 18:29 , Greg Parker <gparker at apple.com <mailto:gparker at apple.com>> wrote:
>> 
>>> On Feb 10, 2016, at 5:45 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hey, everyone. Here's a small feature with ABI implications, ready for feedback. In addition to comments on the proposal itself, I'm also interested in hearing how often this comes up for people:
>>> 
>>> - extending a class you don't own
>>> - to add an overridable method
>>> - where some of the overriders might be outside the current module
>>> 
>>> Jordan
>>> 
>>> https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable-members-in-extensions.md <https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable-members-in-extensions.md>
>>> 
>>> ---
>>> 
>>> Overridable Members in Extensions
>>> 
>>>  <https://github.com/jrose-apple/swift-evolution/tree/overridable-members-in-extensions#library-evolution>Library Evolution
>>> As with any other method <https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#classes>, it is legal to "move" an extension method up to an extension on the base class, as long as the original declaration is not removed entirely. The new entry point will forward over to the original entry point in order to preserve binary compatibility.
>>> 
>> What happens if the base class adds an independent implementation of the same method?
> 
> If it's an @objc method, you're hosed, just like you always were, but at least you'll (probably) find out when you recompile. I don't think there's anything we can do about this other than banning @objc methods in extensions, and I don't think that'll fly.
> 
> If it's a Swift method, it's not the "same" method; it's just another method with the same full-name. Existing binaries won't conflict. When you recompile, though, you'll get a conflict, and we don't currently have any annotations that allow you to fix that conflict, or for subclasses in a client module to deal with the intermediate module not yet having fixed the conflict. This isn't specific to extensions, though; you have the same problem with methods declared in the class body.

Good. I think that is the best result we can hope for here.

>>>  <https://github.com/jrose-apple/swift-evolution/tree/overridable-members-in-extensions#future-extensions>Future extensions
>>> 
>>> The restriction that an extension cannot override a method from another module is intended for safety purposes, preventing two modules from each adding their own override. It's possible to make this a link-time failure rather than a compile-time failure by emitting a dummy symbol representing the (class, member) pair.
>>> 
>> 
>> Dummy symbol enforcement only helps when two conflicting modules have a linkage relationship (i.e. one links to the other). It won't catch the case where two independent modules collide.
> 
> If two linker modules provide the same public symbol, that won't cause an issue?

No, at least not with OS X two-level symbol lookup. If some linkage unit tried to use that symbol and linked to two different providers of the symbol then you would get a link-time error. Otherwise there wouldn't be any link-time or load-time problems.


-- 
Greg Parker     gparker at apple.com     Runtime Wrangler


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