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

[Tino Heth]

> Am 07.07.2016 um 02:27 schrieb Jonathan Hull via swift-evolution <swift-evolution at swift.org>:
> 
> 	1) This method MUST be overridden
> 	2) This method should NOT be overridden
> 	3) This method MUST be called
> 	3) This method should NOT be called except by subclasses
> 	4) This method should NOT be called except by a method override calling super
> 	5) This method MUST call super
> 	6) Overrides of this method should NOT call super
> 
> If we are attempting to bring thoughtfulness to the design of classes, I would like to see things be extendable by default, but with annotations that thoughtful framework designers can use to designate how a particular method should be used.  In most cases, it should not explicitly forbid the end user from subclassing, but require them to acknowledge that what they are doing is not intended by the framework. (e.g. "unsafe override func"…).  That would feel 1000x more swifty to me.  Opt-out safety.
totally agree:
I'm not sure what 3) should mean, but imho several points on this list are much more useful than the ability to seal a class.
Imho it is not necessary to forbid overloading at all, it's better to make sure everyone trying to do so is aware of the dangers (imho exclamation marks would be a "swifty" choice: "override! func(…)).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160707/50569c5c/attachment.html>