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

Scott James Remnant scott at netsplit.com
Wed Jul 6 18:47:41 CDT 2016

> On Jul 6, 2016, at 4:34 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>> To give you an example of the confusion, here is code made perfectly legal by SE-0025:
>>   public final class Example {
>>     overridable func foo() {}
>>   }
> I have no idea how you think this is related to SE-0025 (scoped access control).  I also don’t understand why you think an `overridable` method in a `final` class would be legal under any proposal.  That is nonsense and clearly in error.

SE-0117, which we are reviewing here, in its introduction introduces the new `subclassable` and `overridable` modifiers in a discussion about `public`, and indicates that they are used instead of that keyword. This to me strongly implies that these are in the same family as the access control modifiers.

SE-0025 removes the error when the access of a member within a type is less restrictive, thus removes the error that would otherwise occur with the above code.

Consider this another strong argument for keeping access and inheritability separate, the following code would be obviously an error/warning since `open` makes no sense within a `final` class:

  public final class Example {

    public open func foo() {}


Clarity is always a goal for Swift. This to me has more of it than replacing `public`.

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

More information about the swift-evolution mailing list