> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
