> The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > > * What is your evaluation of the proposal?
+1. Being able to control how a class from my libraries are going to be used by third-parties could enable a better designed API with more control of how it is intended to be used. I'm just not fond of using the proposed keywords ('subclassable' and 'overridable') as they feel more like protocol or attribute names; I'd be more inclined to use the alternative 'public open' instead, or 'public(open)' as a second option. > * Is the problem being addressed significant enough to warrant a > change to Swift? I'd say it is significant to every language. > * 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? C# uses the keyword 'virtual' to explicitly mark methods that can be overriden (not considered in the alternatives but I'm not a big fan of it). > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? I've took (a small) part on the thread discussing this proposal but followed it closely _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution