[swift-evolution] access control

[Ilya Belenkiy]

I hope that access control can be revisited. It is the number one complaint about Swift that I hear from experienced developers. The current solution came as a complete surprise to every ObjC developer I've talked to. The natural expectation was that a strong access control system would be part of a strong type system. I already submitted a pull request with a proposal for this after a lengthy discussion here, but so far it was ignored. I hope that this can be revisited. Even if most people who responded earlier in this list decided that they were happy with the current state, it represents a tiny fraction of people using the language, and at least all the people I talked to strongly disagree but just aren’t on the list.

Right now access control is file based and not API based. This is much easier to implement but useless to express that certain elements of a class are implementation details that are not meant to be used anywhere else (someone can add more code to the same file and get access to the implementation details without modifying the class). It’s also impossible to hide APIs that are meant only for customization points of subclasses.

Some of these problems could be solved with a convention like putting _ in front of protected and __ in front of private methods, and Cocoa uses a similar approach today. But this “solution” is in the same category as using prefixes to determine types. If Swift aims to have a strong type system, and it’s described as one of advantages of Swift over ObjC, it should help enforce this at the language level.

.NET has a good solution that respects the OOP terminology and deals with accessibility in modules and at the API level:
https://msdn.microsoft.com/en-us/library/wxh6fsc7.aspx

I think that a similar approach would work much better in Swift.

—
Ilya Belenkiy