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

[John McCall]

> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution <swift-evolution at swift.org> wrote:
> 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.

I don't think that defaulting to non-open would be a good idea.  Like I covered in the proposal, inherited open methods remain open; letting an override implicitly close off an open method would create a pretty unfortunate error-of-omission situation.

We could remove the default here and require the method to be explicitly open/nonopen/final, but then we really do pile up the modifiers:

  public open override func foo()

To me, the fact that it's already marked with "override" suggests the possibility of open-ness enough to remove the need to re-state it.  I can see why you might disagree, though.

John.

> 
> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution