> * What is your evaluation of the proposal? +1 In its third revision I like this proposal more. I think “open” is a good keyword for both members and classes. I’m in favor of the first design for open classes. That said, I also acknowledge that subclassing without overriding anything doesn’t suffer from the problems that overriding members do. Additionally, even for a sealed class, new methods could be added thought extensions. This means the the benefits of the first design over the second one are fairly small. However, in my experience (which might be wrong), designing a class for subclassing without any overridable methods is quite uncommon, and in the first design can easily be resolved by making it open. I see it as a benefit of the first design that it allows for this distinction (a class can be make public without being subclassable).
> * Is the problem being addressed significant enough to warrant a change > to Swift? Yes. > * Does this proposal fit well with the feel and direction of Swift? Yes. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? I’ve encountered virtual functions in C++ but only to a small extent. I like this solution better because it makes the distinction between internally and externally overridable (and gets out of the way for internal overrides). > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? Read the proposal and much of the discussion (but not all, there’s been so much 😉) - David
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
