[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jordan Rose]

> On Jul 11, 2016, at 08:13, Leonardo Pessoa <me at lmpessoa.com> wrote:
> 
> Jean, given this proposal it will be possible if the developer of the
> library intends so. You'll have to have unsealed classes to be able to
> subclass them and unsealed methods so you can override. It is possible
> to just allow subclassing without allowing overriding, just like
> final.
> 
> As for conflicts I don't think so. If you declare a new method with
> the same name as an existing one without overriding, it will become a
> new method and the base class won't even know that new method exists.
> C# allows this but uses the keyword new (instead of override) to
> clarify a new method is being introduced instead of the existing one
> but as far as I see there is no such need in Swift. I'm also not sure
> we can override a method inside an extension but if so, this provides
> a new point of extension inside a class that is not subclassable.

This is something you’d need if the client were itself a library that couldn’t break backwards-compatibility by renaming its conflicting method. We could either have a “new” or “nonoverriding” annotation or a way to rename methods while preserving their binary interface, but 

You cannot safely override a method inside an extension unless you also control the original method. See my analysis in this draft of a future proposal <https://github.com/jrose-apple/swift-evolution/blob/dc5b0cd7d646c161ede08800cdb4ec90286c6a44/proposals/nnnn-overridable-members-in-extensions.md>.

Jordan

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