[swift-evolution] [Review] SE-0026 Abstract classes and methods

[Evan Maloney]

> Without getting into a protracted argument, I just want to reiterate that:
> 
> * Foundation and Cocoa remain (and will remain for years) a critical part of Swift software development.
> * These frameworks are built around inheritance hierarchies; what you can do to retrofit POP onto them is quite limited. If I want a partially customized UIView that makes changes through the existing API hooks I'm going to subclass, not create a protocol.
> * These frameworks already contain classes and methods that are 'abstract', where that status is enforced through documentation or runtime asserts. This is, in my opinion, a hole that should have been filled a long time ago (but, for various technical reasons, couldn't); we have a chance now to do exactly that.
> 
> In terms of whether or not it's worth making changes to Swift et al 'just' to improve Objective-C interop...I think the community has pretty much decisively come down on the side of yes (see: typed selectors, importing of user-defined Objective-C generics as Swift generics, systematic renaming of imported Objective-C method names to conform with Swift compatibility...).
> 
> Austin

I couldn't agree more with Austin.

I feel like where getting close to a religious argument where the solution to everything is protocols.

The fact is, classes exist as first-class entities in Swift. Abstract classes solve a need that is only partially solved (and in a much more convoluted fashion) by protocols.