[swift-evolution] 'Public' class visibility specifiers

[Xiaodi Wu]

On Tue, Feb 21, 2017 at 1:20 PM, David Waite via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Feb 21, 2017, at 3:47 AM, Joanna Carter via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> Le 21 févr. 2017 à 10:28, Slava Pestov <spestov at apple.com> a écrit :
> >>
> >> There is one important difference, but it is rather obscure. ‘final’
> allows a class to conform to protocols where ’Self’ appears in invariant
> position in requirements. For example, say you have the following:
> >>
> >> …
> >> Also worth noting that removing ‘final’ from a class is going to be an
> ABI breaking change (and source compatibility too), whereas changing a
> ‘public’ class to ‘open’ poses no such difficulty.
> >>
> >> I might be in favor of a proposal to just remove ‘final’ altogether,
> though, leaving us with just open and public. I’m not sure how much the
> ability for classes to conform to such protocols matters in practice.
> >
> > I am not advocating removing 'final' from the language ; rather of
> removing 'open', which is "foreign" to anyone coming from any other
> language.
>
> C# has a very similar concept of sealed members. In C++, members cannot be
> overrided unless they are declared virtual.
>
> C++ however lets you declare the same member in a subclass without it
> being used by superclass members or when invoked as the super type - this
> is mostly because code often don’t use polymorphism in C++ due to the
> performance and memory impact.
>

Doesn't Kotlin have `open`? I believe it's used slightly differently, but
from the perspective of a user of a third-party library I think the effect
is the same in both languages.

> My suggestion was to revert 'open' back to 'public' for visibility
> purposes and to use 'final' as the means of controlling
> inheritance/overriding that it has always been.
>
> I’m not sure if you mean only controlling overridability at the type
> level, or defaulting to overridable. I can make strong counterarguments for
> retaining current behavior in both cases.
>
> >
> > IMO, it is 'open' that is superfluous to requirements.
>
> Open is not about requirements. Open is about maintaining invariance of
> state and proper thread safety as required by the implementation of the
> superclass.
>
> If the goal isn’t to work within the bounds of a superclass
> implementation, protocols are a much more appropriate way to describe
> requirements
>
> -DW
> _______________________________________________
> 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/20170221/82663665/attachment.html>