> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa <[email protected]> wrote: > > So I did get what you meant right. Now tell me: if a class or method > is internal to your module (and you know internal means only you, > throught your source code, inside your app or library can extend it), > do you really need to mark anything as final for any reason? Final on > any non-publics is a restriction you put on yourself, you will always > have the power to lift that at any time (as long as you still own the > code, of course) so you are always in control of your subclasses and > overrides. All the time. It's up to you to subclass/override or not. > This is different from what you make public: you either have no > control or you have to fine grain control making everything final. You > regain that control over your publics with this proposal. >
The same argument could be applied to why we have `fileprivate` and `private`, if a class or method is internal to my module, why do I need to mark anything as further private for any reason? There are a whole bunch of answers; perhaps the module is maintained by a team of twenty people, and the class is intended to be sub-classed within the team, so it’s a level of “internal public.” It doesn’t even have to be a team, maybe I’m writing a utility class that I know I’ll use for years, and I know I’ll forget my rationale later down the line and make the mistake of overriding something I shouldn’t. Removing `final` is a whole proposal unto itself that I would also -1, it’s not covered by this one, so at this point this is a rabbit hole. Scott _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
