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

Kevin Ballard kevin at sb.org
Sat Jul 9 17:17:17 CDT 2016

On Tue, Jul 5, 2016, at 04:11 PM, Chris Lattner wrote:
> 	* What is your evaluation of the proposal?

Mixed bag.

I'm a big fan of sealed-by-default for classes. But I want a keyword (e.g. `sealed`) for this so I can be explicit about it too. Just as I sometimes mark methods as `internal` to make it clear to the reader that I didn't simply forget the access modifier, I would want to mark certain classes as `sealed` to make it obvious that I made a deliberate choice.

On the flip side, I'm very against sealed-by-default for functions. My general feeling is that, if my class is subclassable, marking certain public methods as non-overridable is the exception rather than the norm. Anecdotally, in the Postmates app, most of our Swift classes are explicitly marked as `final` (which supports sealed-by-default for classes), but for the subclassable classes, I'm pretty sure that _none_ of our methods are marked `final`.

Also, I think the keyword `subclassable` is kind of cumbersome. I'm much more in favor of `open`, or possibly `public(open)` since this keyword only applies to public classes (or public methods, if I'm overriding a sealed method from my parent).

And finally, I think we need to make the Swift migrator automatically mark public non-final declarations as `open`, otherwise we have a *huge* backwards compatibility hazard for all third-party Swift frameworks.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?


> 	* Does this proposal fit well with the feel and direction of Swift?

Yes. It's making things safer by default, and matches the default internal access level.

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading of the proposal, then reading part of this massive review thread and skimming the rest.

-Kevin Ballard

More information about the swift-evolution mailing list