[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown]

* What is your evaluation of this proposal?

A reluctant +1. I’m reluctant because I actually do love the flexibility in Obj-C to subclass where I feel appropriate, and feel the limitations of this are going to be difficult to get used to.

From what I see, however, “final” as a concept makes this more compelling. Being able to retroactively add final to a class is a great benefit for libraries, and this won’t be possible if we allow subclassing by default. Additionally, designing for subclassing is important and really should be considered at design time. I also think we need to flesh out the subclassing in this proposal where there are requirements to the override etc, but I agree in general with this concept.


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

There are multiple problems that this addresses. A change is definitely needed here to resolve them, whatever the form these changes take.


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

Clarity at requirements for subclassing, and being more specific, seems in the direction of Swift.


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

I’ve used plenty of languages with subclassing, focusing most on Obj-C. I love the freedom to subclass in this language, but it’s fair that this is not the safest practice. Obj-C seems to be the wild west for subclassing.


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

I’ve read the proposal, followed the conversation, and was involved in the first discussions about this earlier in the year.