> On Jul 14, 2016, at 5:56 PM, David Waite <[email protected]> wrote: > > >> On Jul 14, 2016, at 4:18 PM, Paul Cantrell via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> On Jul 14, 2016, at 4:39 PM, Chris Lattner <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> [The core team] asks the community for an in-depth discussion of the >>> secondary points of the proposal: does it make sense to require every >>> member to be marked as “overridable” in order to be overridden by an open >>> subclass outside of the current module? > > I don’t see a reason for the openness/overridability/virtualness/finalness of > a member to be more complex than a boolean. That is, while classes can be > final, sealed or open, I believe members should only be “open” or “final”. I > don’t see use cases to have members that are only overridable in-module but > not by external parties.
I tend to agree with that. The “overridable internally, final for the public” mode seems like it might have some use, but feels awfully esoteric. >> This makes me wonder whether we should remove member-level “final” from the >> language, and require “overridable” (i.e. final methods by default) even for >> members of non-open classes just for consistency and simplicity. That may be >> a separate proposal, but does seem like it needs consideration for Swift 3. > > In an inheritance chain, we have to decide whether a subclass inherits the > method openness. If so, “final override” could still be valid. Otherwise, I > agree about removing member-level ‘final’ My gut feeling is that “final override” is also a bit esoteric — too much to justify keeping a whole keyword in the language. A compelling use case for either of these allegedly esoteric things could easily sway me. Cheers, Paul
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
