I was a little confused by this - I believe the previous proposal involved replacing final (and assuming it unless opened).
I do not support "sealed". -1000 from me. I would absolutely holeheartedly support "final" by default; it's not very different to turning WMO on by default - and actually since we did so, classes you don't open up or internally subclass are implicitly final already, so it fits really nicely. I don't want there to be both "sealed by default" and "final" in the language describing the same concept; it's confusing, users won't know immediately which is the standard behaviour. I also don't agree with a "final outside module" (sealed) attribute - it's an ugly compromise because we don't want to anger subclassers, but at the same time we clearly arent convinced by their arguments. This is a cowardly concession which makes the language uglier and less easy to reason about, just so complainers will keep quiet. If the core team believes subclassability should be explicit, make it explicit everywhere. It honestly doesn't come up too often, and when it does tacking an 'internal(open)' isn't the hardest thing to make people do. It would make all code involving classes much easier to locally reason about - "is this class overridden? By whom? How much freedom do I have to change things? Oh, all of the subclasses are internal? That's great, change away..." We don't have header files any more. Our source should be maximally self-documenting; not just for the compiler and optimisation potential, but for human beings too. Karl Sent from my new Email (https://itunes.apple.com/app/apple-store/id922793622?pt=814382&mt=8&ct=my_new_email) > > On Jul 18, 2016 at 8:57 PM, <Leonardo Pessoa via swift-evolution > (mailto:[email protected])> wrote: > > > > Nevin/Garth, please remember final and sealed are two different > concepts: final prevents anyone from subclassing/overriding while > sealed prevents from subclassing/overriding *outside* the module they > are declared. Thus final is not the same as sealed. > > L > > > On 18 July 2016 at 15:45, Nevin Brackett-Rozinsky via swift-evolution > <[email protected] (mailto:[email protected])> wrote: > > 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 > > <[email protected] (mailto:[email protected])> 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 > >> [email protected] (mailto:[email protected]) > >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] (mailto:[email protected]) > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list (mailto:[email protected]) > [email protected] (mailto:[email protected]) > https > (mailto:[email protected])://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
