[swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

[Károly Lőrentey]

> On 2016-07-12, at 01:54, Colin Cornaby <colin.cornaby at mac.com> wrote:
> 
>> - Slippery Slope: SE-0117 adds yet another entry to the already huge list of things in Swift that subtly or openly discourage people from subclassing. How far are we from someone seriously proposing to outright rip inheritance out of the language? Enough is enough. Stop with the anti-subclassing propaganda. Implementation inheritance is a hugely important core language feature whose popularity should be preserved and whose use should be encouraged and celebrated.
> 
> This is another reason I’m unclear on the reasoning behind this proposal, but I could be missing something… Structs have been pushed in Swift primarily as classes without polymorphism. One would think that one of the primary reasons to adopt a class structure in Swift is polymorphism. It seems backwards to make the point of a class primarily polymorphism, and then disable it by default.

Classes are the only way to create a reference type in Swift. In idiomatic Swift code, classes are frequently employed for this exact feature alone (to e.g. implement copy-on-write storage).

Subtype polymorphism is an additional feature that is (while obviously important and useful elsewhere) frequently unwanted in this context. One can easily imagine a bizarro alternate universe where Swift classes do not support subclassing at all, and they would still remain a quite useful construct. Polymorphism (when needed) is often better achieved using protocols rather than subclassing, anyway.

(Note that we clearly do not live in that universe. I don’t think it would be a good idea to remove subclassing from Swift.)

> I suppose you could make the case you’d want to inherit from a parent class but not allow other classes to inherit from you. This just seems like more of a mess though. I could have vendors shipping me view controllers that I can’t inherit from, complicating my own designs.

We already have final, so this is already the case today. For what it’s worth, I’ve already made many of my own view controllers final; but I’m not vending them out to people.

> (The other big reason I still use a lot of classes in Swift is Cocoa compatibility, but I’m assuming Obj-C compatible Swift objects won’t support final or final-by-default anyway.)

That is a good question; @objc and final are not mutually exclusive today. I think cross-module subclassibility should work the same way.

> Someone correct me if I’m missing something big here though.


-- 
Karoly
@lorentey