[swift-evolution] Final by default for classes and methods

[Kevin Ballard]

On Mon, Dec 7, 2015, at 11:19 AM, Joe Groff via swift-evolution wrote:
> There's a refinement of this idea we've discussed internally in the past.
> Instead of making classes final by default, we could make it so that
> public classes are not subclassable from other modules by default.

I like this. I'm not convinced that this is something we should actually
do, but it seems like a better thing to make default than
final-by-default.

Regarding subclassing, I am sympathetic to the idea that it's a good
idea to mark classes as final. In my own experience, I've found that
just because you are capable of subclassing a class doesn't mean the
class will actually behave sanely when subclassed. I've adopted a
personal style of always defaulting my classes to final unless there's a
reason to allow subclassing, but this is also in the context of
application development (where you don't have to worry about
out-of-module subclasses anyway). In the context of framework
development, there's a lot more motivation to allow subclasses (because
you don't always know what behavior will need to be extended), and so
defaulting things to final-by-default will discourage that. Of course,
defaulting to sealed-by-default has a similar effect, and that's why I'm
not convinced that it's actually a good idea, but it does seem less
restrictive than final-by-default.

Another option would be to use sealed-by-default but to add a keyword
that means "subclassable" (such as `open`), and emit a warning whenever
a public class does not specify its subclassing nature; the warning
would be suppressed when explicitly marking the class as `sealed`,
`open`, or `final` (assuming of course that we add a keyword for
`sealed` to begin with).

-Kevin Ballard