[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Paul Cantrell]

> On Jul 14, 2016, at 5:56 PM, David Waite <david at alkaline-solutions.com> wrote:
> 
> 
>> On Jul 14, 2016, at 4:18 PM, Paul Cantrell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Jul 14, 2016, at 4:39 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160714/346602bb/attachment.html>