Then we would need another keyword to close the method again should we need/want.
public sealed override func foo() I don't see any association between override and open/sealed as they relate to two different aspects of class inheritance. One declares the method is overriding a superclass method; the other that this method can(not) be further overriden. With inherited openness, it should be possible to revert it and defaulting to inherited openness will demand the introduction of another keword (sealed/closed/nonopen). It would be simpler to have one global default and one keyword only. Two keywords add to complexity to learn the language. L On 18 July 2016 at 14:12, John McCall via swift-evolution <swift-evolution@swift.org> wrote: >> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution >> <swift-evolution@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution