Sent from my iPad
> On Jul 6, 2016, at 6:39 PM, Scott James Remnant <sc...@netsplit.com> wrote: > > >> On Jul 6, 2016, at 4:34 PM, Matthew Johnson <matt...@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. > > Scott
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
