* 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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
