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

[Michael Peternell]

> Am 06.07.2016 um 01:11 schrieb Chris Lattner via swift-evolution <swift-evolution at swift.org>:
> 
> Hello Swift community,
> 
> 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
> 
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
> 
> 	https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
> 
> 	* What is your evaluation of the proposal?

-1
I think it's a step backwards.
If we really think that Swift is meant as a language for beginners then this is certainly the wrong direction to go to. Having to use a special keyword to allow a class to be subclassed from outside the module looks like the compiler has to perform some extra effort to add this "subclassability feature".

It's not bad to allow sealing of classes. I don't see real value in it though. And `sealed` should not be the default. Either the class if final or not: for me that's a valuable distinction. "sealed vs. unsealed" is not.

The proposal is another try to prevent people from misusing the language. But misusing the language will always be possible and will always be easy. All these attempts will make the language just more complicated or harder to understand. I don't buy the performance argument either, i.e. that "sealed by default" will improve performance considerably for non-contrived use-cases. But I'm sure you will find that out a few months after the proposal is implemented :-/

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

No

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

No, I don't think so.
If you have a ParentClass and a SubClass, and the ParentClass is sealed while the SubClass is subclassable. What happens? No matter how this question is answered, I don't like the answer. (compile error => bad. || make it as the user wishes => bad; what do we gain by letting ParentClass remain sealed? || make ParentClass implicitly subclassable too => bad.)

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

No

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

Participated in early discussions which didn't convince me at all.

-Michael

> 
> More information about the Swift evolution process is available at
> 
> 	https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution