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

Rod Brown rodney.brown6 at icloud.com
Sat Jul 16 02:25:16 CDT 2016

Review link: 

* What is your evaluation of the proposal?
+1 for the implementation. +0.5 for the concept. I think this is a clean interface for what open should be, and am glad at the simplification. This seems very "Swifty", and much better than the first proposal. I'm concerned that this may be over-limiting developers, and while everything looks great in theory, I am concerned that this may not be a good decision for real-world development. That said, I also think there are real wins in the ability to at a later date finalise a class for performance reasons, and provides clear structure for how a subclass is designed be used.

 * Is the problem being addressed significant enough to warrant a change to Swift?
I think that sorting out our inheritance story for public frameworks is important if we are going to start seeing public Swift Frameworks in the wild more often.

 * Does this proposal fit well with the feel and 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 haven't. I've used Obj-C a lot. The ability to fix some issues with patching leads me to be concerned that we are overly restricting things here.

 * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I've been following the threads since this discussion started months back, in discussions recently over it, and have read thoroughly both reviews.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160716/60e2462e/attachment.html>

More information about the swift-evolution mailing list