> On Jul 6, 2016, at 4:34 PM, Matthew Johnson <[email protected]> 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.
Scott
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
