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

[Leonardo Pessoa]

Nevin/Garth, please remember final and sealed are two different
concepts: final prevents anyone from subclassing/overriding while
sealed prevents from subclassing/overriding *outside* the module they
are declared. Thus final is not the same as sealed.

L


On 18 July 2016 at 15:45, Nevin Brackett-Rozinsky via swift-evolution
<swift-evolution at swift.org> wrote:
> Garth makes an excellent point. Károly is correct that we can already
> achieve “sealed” by making a `final` member call through to an `internal`
> one.
>
> Therefore, it seem clear that “open” should only be applicable to classes,
> not to members. This should simplify the proposal nicely.
>
> Nevin
>
>
> On Mon, Jul 18, 2016 at 2:39 PM, Garth Snyder via swift-evolution
> <swift-evolution at swift.org> wrote:
>>
>> > Károly wrote: I suggest we change the proposal to remove the implicit
>> > "sealed" level of public member overridability, and support only "open" or
>> > "final" class members. For members, "open" should mean the opposite of
>> > "final", with no levels in between. Member-level openness should be entirely
>> > independent of visibility; so it should be possible to say "internal open"
>> > to mean an internally overridable member that's not at all visible outside
>> > the module -- the same as today's default.
>>
>> What is the distinction between this approach and simply omitting the
>> ability to apply the “open” keyword to anything but a class?
>>
>> The current behavior is (IIUC) that you cannot override a superclass’s
>> final method. Aside from that, you can override any other method that’s
>> visible to you, wherever you stand with regard to the superclass’s origin.
>> If there’s no sealed status for members, why is any change to member
>> annotations needed at all?
>>
>> Garth
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>