[swift-evolution] [Proposal Draft] Remove open Access Modifier

[Dimitri Racordon]

On 21 Feb 2017, at 13:19, Brent Royal-Gordon <brent at architechies.com<mailto:brent at architechies.com>> wrote:

Really? Three sentences presenting an unsupported opinion?

I’ll concede that the proposal makes a claim that might very well be disproved. I would very much like to see an actual example of a public class that **has** to be public but **shouldn’t** be open for obvious reasons. I would happily accept being shown wrong on that point.

Besides, I don’t claim this use-case never happens, but only that it is not so common. Although, this remark wasn’t included in the proposal, I also claim that for those instances, the risk involved is generally be acceptable. To some extent, this opinion is also shared in SE-0117:

“Within a single module, this can be tolerable, but across library boundaries it's very problematic unless the superclass has established firm rules from the beginning.”

The idea is to say that if the use-case is rare (once again, I’d accept being shown wrong here) and the problems it involves are tolerable, then the added complexity induced by an additional access level and its keyword is not worth it.

Like SE-0117, I too advocate that “designing a class well for subclassing takes far more effort than just designing it for ordinary use”. My belief however is that `open` doesn't fixes this issue. Instead, it hinders considering marking an entity `final`, as one may think that `public` is safe enough. In addition, the role of `final` for public entities becomes unclear for the library user, as anything not marked `open` can be understood as `final` anyway.

The asymmetry induced by `open` in the language is a fact. As stated by the documentation: “Open access applies only to classes and class member”. I’d be tempting to say that asymmetry in any system adds complexity to the said system. To the very least, it makes the asymmetry an exception to know about.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/715b7904/attachment.html>