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

[Tino Heth]

> Publishing a library is a promise of something. It ought to only be promises the library author wants to make. If “the truth” is “the implementation in the current version of the library”, that’s definitely not what a library author should promise. That’s true for plenty of things, not just whether or not overriding is expected.
Correct, library users shouldn't have to puzzle over the authors intention, but I wasn't referring to source when I wrote about truth.
A good library should strive for flexibility, and don't impose restrictions that aren't necessary — "lack of extendability" imho is no promise an author should want to make.
So, what if he wants to promise extendability, but just isn't sure he will be able to stand by this promise? Instead of forcing him into lies, we could as well accept the reality of "I'm not sure", which imho would be the most reasonably default, as it doesn't pretend an explicit choice when there is only uncertainty.

Jonathan Hull outlined an alternative to 0117 (http://article.gmane.org/gmane.comp.lang.swift.evolution/23761 <http://article.gmane.org/gmane.comp.lang.swift.evolution/23761>) which takes that into account — and imho has additional benefits:
- More power (for example, UIView.drawRect and other methods that shouldn't be called by clients could be modeled)
- Less confusion ("What's the point of subclassable and overridable? It has no effect on the ability to subclass and override in my app at all!")

Tino
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160713/a88cfad9/attachment.html>