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

[Greg Parker]

> On Feb 10, 2016, at 5:45 PM, Jordan Rose via swift-evolution <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?

> 
>  <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.

The old ObjC "qualified selectors" proposal handled a similar situation by mangling the original provider of the overridable method into the method name. This makes evolution trickier (you need to preserve the same mangled name even if the method moves into the base class or into a different module). On the plus side it allows independent extensions and subclasses to do independent things. It also preserves binary compatibility of those extensions and subclasses if the base class adds its own unrelated method with the same name. (Source compatibility in that case is not preserved. The extensions and subclasses would need to add further annotations to preserve their independence when recompiled.)


-- 
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/94a2998c/attachment.html>