[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly
matthew at anandabits.com
Wed Jul 6 19:34:14 CDT 2016
Sent from my iPad
> On Jul 6, 2016, at 6:39 PM, Scott James Remnant <scott at netsplit.com> wrote:
>> 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.
Great! I agree with you that the specific details of the proposal can be improved. The core team is free to "accept with revision" and that's what I hope they do in this case.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution