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

Scott James Remnant scott at netsplit.com
Wed Jul 6 18:39:53 CDT 2016

> On Jul 6, 2016, at 4:34 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> Many of us believe “final” is too blunt a tool.  There are many cases where final cannot be used but you still don’t want external users subclassing or overriding.  
> We would like a more precise tool for these circumstances and believe if it is going to exist in Swift it should be the default.  Its behavior follows the principle of requiring programmers to explicitly make decisions about what behavior is exposed outside of a module.  You may not like that principle, but it is one that has been embraced by the language.

I am all for these things, and would be in favor of a proposal that does this cleanly(*)… the proposal text I reviewed does not.

* e.g. the final/sealed/open keywords you suggest, with sealed being the new default, makes a huge amount of sense to me and feels clean, since it keeps access and finality separate, and as you say, explicitly make decisions in a manner otherwise consistent with the language.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160706/46691aab/attachment.html>

More information about the swift-evolution mailing list