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

[Evan Maloney]

> - What is your evaluation of the proposal?

I could not more strongly support the proposal to add abstract classes, functions and properties to Swift.

None of the proposals involving protocols as a solution to this have addressed the fundamental issue:

*ONLY* abstract classes ON THEIR OWN allow the compiler to enforce providing an implementation for a given function.

For example -- and not picking against the author of this, it's just the most recent example to grace my inbox:

> I am against the proposal because I feel it goes against the Protocol Oriented Programming patterns found in the Swift Standard Library. Current protocol functionality can provide a solution for the given example. If a protocol property is not implemented, the compiler will not let you compile. 

This does not address the fundamental concern of abstract classes.

Yes, a protocol will force you to provide an implementation. However, a protocol *by itself* cannot force the implementor of a class to provide an implementation unless that class declares itself in conformance with that protocol.

ONLY an abstract class, ON ITS OWN, can force concrete subclassers to provide an implementation for a given thing.

Protocols can't do this, because if you forget to declare conformance with the protocol, the compiler can't enforce anything. This pushes what could be caught at compile-time to a runtime (potentially crashing) problem.

Abstract classes enforce a requirement that a given portion of the class hierarchy provide an implementation of X.

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

Yes.

> No, protocols implement this functionality, but with a different syntax. There is no lacking or additional functionality this proposal provides.

No, protocols *do not implement* this functionality. They provide something else, and are orthogonal to the class hierarchy.

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

Absolutely. Swift is about safety, about letting the compiler perform safety checks. ONLY abstract classes allow the compiler to enforce that an implementor of a given subclass has provided an implementation for a given function.

Solutions that require the use of protocols can only be checked for correctness if the implementor of the subclass in question ALSO declares conformance to the protocol.

In other words, a protocol-based solution can only be checked by the compiler if the developer does 2 things correctly (declares protocol conformance and provides an implementation), whereas abstract classes allow the compiler to perform checks as long as the developer does 1 thing (subclass a given class).

> No. It goes against protocol oriented programming.

Swift isn't ONLY about protocol oriented programming. Classes are here for a reason, and they should not be relegated to second-class status where people refuse to consider class-only functionality just because the concept can't be shoehorned into something protocol-related.

> Furthermore, this is only for classes, structs are being excluded in this case. I feel that with most of the standard library being implemented as structs, this is not acceptable.

Rather than reject this proposal because "this is only for classes," perhaps recognize that this is only for classes PRECISELY because this type of problem--the one that abstract classes addresses--only occurs with a class hierarchy.

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

C++ and have found them EXTREMELY useful. This proposal is in line with that.

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

I've been following this discussion very closely, and before I realized there was already a proposal in the queue for abstract classes, I also wrote a similar proposal:

https://gist.github.com/emaloney/d0b5bf7dd831d4f7415c



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160303/6d17a3ca/attachment.html>