The review of SE-0026 "Abstract classes and methods" ran from February 26...March 4, 2016. The proposal has been deferred from Swift 3. Discussion centered around whether abstract classes fit in the direction of Swift as a "protocol-oriented" language. Beyond any religious dogmas, Swift intends to be a *pragmatic* language that lets users get work done. The fact of the matter today is that one of Swift's primary target platforms is the inheritance-heavy Cocoa framework, and that Swift 2's protocols fall short of abstract classes in several respects, including:
- Protocols can require conforming types to provide properties, but extensions cannot instantiate storage into conforming types. Every conforming type must today satisfy a protocol's storage requirements itself.
- Type erasure is easier to accomplish using abstract base classes with generic subclasses. Protocol existentials today only support all-or-nothing type erasure, and don't support protocols with associated type or Self constraints at all.
- Protocols don't support language enforcement of separate implementor and user interfaces, since all of a protocol's requirements must be as visible as the conformance. An abstract base class can expose private or internal abstract requirements to its implementation subclasses while exporting a different interface for external users.
- Protocol extensions can provide default implementations, but there's no equivalent to 'super.' today for a concrete implementation to be able to chain up to a default implementation.
Unfortunately, the core team is currently bandwidth-constrained and can't immediately participate to the degree we'd like in the design of this important feature. Furthermore, "completing generics" is one of our primary goals for Swift 3, and proposals for addressing many of the above limitations with protocols are in various stages of discussion and design. We'd like to revisit this feature once the core goals of Swift 3 have been addressed, so we can more accurately consider its value in the context of a more complete generics implementation, and so we can address the finer points of its design.
Some things to consider for future revision:
An abstract class cannot be instanciated.
This can be prevented in cases when `AbstractClass(...)` is statically spelled, but the behavior of abstract class metatypes must be specified. Is `let classObject: AbstractClass.Type = AbstractClass.self` allowed? Does `let classObject = _typeByName("Module.AbstractClass")` work? If not, then the abstract class object cannot be used for metaprogramming or generic argument binding purposes. If it can be, then there's a static safety hole, since `classObject.init(requiredInitializer:)` would have to dynamically fail if `classObject` refers to an abstract class metatype.
When declaring an abstract property, you must specify which methods must be implemented : get, set, didSet, willSet.
If you do not specify anything, only setter and getter are made abstract as below :
abstract var url : String
Only 'get' and 'set' are of interest for a property's interface. For consistency with protocol requirements, abstract properties should probably require an explicit '{ get }' or '{ get set }' declaration to indicate whether mutation is expected.
-Joe