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

[Scott James Remnant]

> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa <me at lmpessoa.com> 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