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

[Brent Royal-Gordon]

> https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md
> 
> 	• What is your evaluation of the proposal?

-1.

Swift already has a means to create abstract types; we call them "protocols". Protocols cannot yet do all of the things that abstract classes can. But I think we would be better served by enhancing protocols to fill these gaps, rather than creating a parallel construct which muddies the conceptual simplicity of our current classes.

I believe the missing functionality would include:

1. Being able to constrain a protocol so that conforming types must inherit from a particular class.
2. Being able to use `override` and `super` in a protocol extension as long as the protocol has a must-inherit requirement ensuring the relevant member exists.
3. Being able to declare stored properties in protocol extensions, as long as they were declared in the same module as the protocol.

Three more things would be nice-to-haves:

4. Being able to declare conformance only to the protocol in a class, and have the required inheritance be implied.
4. Being able to add static members which could be called on the protocol itself, not just types conforming to it.
5. Being able to add factory initializers to the protocol which could initialize any conforming type.

With these six features in place, I believe Corelibs Foundation could implement its class clusters (NSArray et.al.) as protocols constrained to subclass NSObject, and clients of both libraries could be source-compatible.

I see the following benefits in going with protocols:

* Draws a bright line between abstract and concrete types.
* Required language changes are incremental.
* No problems with private abstract members of public types; all protocol requirements are already as public as the protocol itself.
* Allows for more flexible application (e.g. `UITextField` can conform to `protocol TextualView: UIView` even though it's actually a grandchild class of `UIView`).

> 	• Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Just not *this* change.

> 	• Does this proposal fit well with the feel and direction of Swift?

No, I don't think so. Currently Swift draws a bright line between concrete and abstract types: protocols are abstract and all other types are concrete. Allowing abstract classes would blur this distinction.

> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have used abstract classes, but only in languages with an "everything is a class" approach. I always found them clumsy and wished for something better.

I have also used languages (including Objective-C) with no effective solution to the problem abstract classes attempt to solve other than the equivalent of `fatalError("not implemented")`. That sucked too. I quite agree with the desire to find a solution to this problem.

> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I have read the proposal and all prior reviews, and participated in pre-proposal discussions.

-- 
Brent Royal-Gordon
Architechies