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

[Nevin Brackett-Rozinsky]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160718/cd850c8b/attachment.html>