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

[Haravikk]

So, having considered this for a while, although I was initially in favour of it, as my background is largely in Java where I used class hierarchies a lot, some work I’ve been doing in Swift that has actually helped me to appreciate protocols and their capabilities a lot more.

I think with this in mind I’m actually now leaning more towards support for mixins plus some kind of implementing type only visibility. Mixins would be a new category of protocol that can include stored properties and overridable/extendable implementation details; my reason for preferring these is that they could be used with structs as well as classes, though I would actually prefer a different name (in fact I’d prefer to think of them as abstract types that are neither a struct or class… yet). Inheriting type only visibility is of course useful for providing partial implementations that a type can/should use, without exposing it as a callable method; I really dislike the idea of using precondition failures or other errors to indicate methods that should not be called directly, as it’s hacky at best, so I think the visibility restriction would provide a much better alternative.


Someone asked in this discussion whether classes are second-class citizens in Swift, and thinking about it some more I kind of think that they are; after a period of adjustment I now use structs for almost everything. I only use classes where a common reference is absolutely necessary, and also for nested types. Nesting and polymorphism can actually both be replaced by type-erased wrappers, though for nesting this may be more work than it’s worth if you’re trying to nest a private type, but it does mean that classes are actually a lot less important in Swift than other languages.