> On Jul 6, 2016, at 4:34 PM, Matthew Johnson <[email protected]> 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`.
Scott_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
