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

[Brent Royal-Gordon]

> On Jul 15, 2016, at 10:52 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> 	* What is your evaluation of the proposal?

I agree with the core team that closed by default for classes is the right move.

I also think that it makes sense for methods to be closed by default. **However**, I am seriously concerned about the source-code impact of this change. I believe there are at least an order of magnitude more public member declarations than public class declarations in most projects. For instance, I attempted (using crude, most likely imperfect regex-based algorithms) to estimate the number of classes, methods, properties, and subscripts in Corelibs Foundation, and got these results:

	class: 120
	func: 1277
	subscript: 6
	var: 707

(Note: I removed obviously incorrect things like top-level constants and functions, but these numbers probably still count some struct and enum members.)

Annotating 120 types is not that big a deal relative to the size of Foundation. Annotating 1,990 members introduces much more clutter and tremendously increases the burden of closed-by-default. I don't think I can support burdening that many declarations with extra syntax; it seems like a lot of red tape for a case where you've already explicitly opted in to subclassing.

That's why I prefer the alternative design of having `open` as a separate access level. I don't think it is a serious burden to have to search for "public|open" when you want to see all public APIs. Nor do I think it's a problem that `open` is short. A short keyword would be a problem if our goal is to actually *discourage* subclassing, but if we merely want people to *think* before they subclass, we should be happy that permitting subclassing and overriding is not encumbered with heavyweight keywords.

Meanwhile, the benefits of an `open` access level are manifold:

* It ensures that unsealing is no more burdensome than sealing.

* There's no need for a "you can't declare it open because it's not public" diagnostic.

* It defuses one of the complaints about this change from its critics, easing acceptance.

As an alternative to having `open` as a separate access level, we could instead have it merely imply `public`: the canonical form would be `public open`, but source code could just say `open`. Generated interfaces would always say `public open`, so searching for `public` in those would work as you want it to.

So, in short:

1. Yes on closed classes by default.

2. No on closed members by default, unless we use a syntax less burdensome than `public open`.

3. I think the arguments against standalone `open` are weak, and I would strongly prefer it to `public open`.

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

Yes.

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

Yes.

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I've used OO languages, but not sealing ones.

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading of this draft, but deep involvement in previous reviews and discussions.

-- 
Brent Royal-Gordon
Architechies