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

[David Waite]

> On Jul 14, 2016, at 4:18 PM, Paul Cantrell via swift-evolution <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:
>> 
>> To sum this all up, the core team is … requesting a revision to change the concrete syntax to “public open class Foo” instead of “subclassable class Foo”.
> 
> Yes, +1 to “public open Foo” instead of “subclassable Foo”.
> 
> Presumably “open” without “public” is an error…?
> 
>> [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. 

As we suspect an API designer to indicate whether a class is overridable or not by third parties and to determine whether members are exposed to third parties, I would expect them to also want to dictate *how* said type is overridable by third parties (e.g. which members are overridable). 

Whether we are open by default or final by default allows them to do this, but transitioning from final to open shouldn’t break existing API usage on revision. You won’t have someone accidentally using your library in a way you didn’t intend to support because you forgot to mark a method as ‘open’. Therefore, I lean toward final by default.

> 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'

-DW

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