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

[Scott James Remnant]

I reviewed the original proposal, and this revised text is a much better step forwards; I still think there are a few changes I’d like to see before fully getting behind it.

Consider this a +0.5.

I like the use of the additional `open` keyword on top of `public`, it has a nice symmetry to the use of the additional `final` keyword for the opposite effect. I’m not totally sold on the actual name of the keyword, but I’m not going to argue over the color of that bikeshed.

That `open` is invalid on declarations that are `final` feels to me like these are keywords of the same family, just as `public` and `private` make no sense together. I like that.


I disagree that an `open` method overridden from a superclass is implicitly `open`.

As the rationale for the proposal states, overridability is hard to get right, and there is no guarantee that the consumer of an API is going to think about it. The default for override methods should not be `open` or `final`, it should be the internal equivalent.

A coder subclassing a public API, who themselves wants their subclass to be subclassable, should need to restate `open` where appropriate.

This also seems to be a general conflict in that you can always reduce the access, e.g. an API might have a `public open` method, but the subclass should be able to declare that as `override private` and thus the `open` keyword would be invalid in this context.


Scott