Garth makes an excellent point. Károly is correct that we can already achieve “sealed” by making a `final` member call through to an `internal` one.
Therefore, it seem clear that “open” should only be applicable to classes, not to members. This should simplify the proposal nicely. Nevin On Mon, Jul 18, 2016 at 2:39 PM, Garth Snyder via swift-evolution < swift-evolution@swift.org> wrote: > > Károly wrote: I suggest we change the proposal to remove the implicit > "sealed" level of public member overridability, and support only "open" or > "final" class members. For members, "open" should mean the opposite of > "final", with no levels in between. Member-level openness should be > entirely independent of visibility; so it should be possible to say > "internal open" to mean an internally overridable member that's not at all > visible outside the module -- the same as today's default. > > What is the distinction between this approach and simply omitting the > ability to apply the “open” keyword to anything but a class? > > The current behavior is (IIUC) that you cannot override a superclass’s > final method. Aside from that, you can override any other method that’s > visible to you, wherever you stand with regard to the superclass’s origin. > If there’s no sealed status for members, why is any change to member > annotations needed at all? > > Garth > > _______________________________________________ > 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