Sent from my iPad
> On Jul 6, 2016, at 6:47 PM, Scott James Remnant <sc...@netsplit.com> wrote:
>
>
>>> On Jul 6, 2016, at 4:34 PM, Matthew Johnson <matt...@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.
SE-0025 says nothing about final though. I really don't think we would allow
overridable in a final class in any case.
I do think it's fair to point out that details like is are not fully specified
in the proposal and should be (in order to avoid another round of cleanup
similar to what was necessary for SE-0025).
>
>
> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
