[swift-evolution] access control proposal
rjmccall at apple.com
Sun Dec 6 23:21:20 CST 2015
> On Dec 5, 2015, at 8:39 PM, Ilya via swift-evolution <swift-evolution at swift.org> wrote:
> I think the it would help a great deal to have an access level modifier that is really private and visible only inside the class itself. Right now, the only way to hide implementation details for a class is to hide the class code in a separate file, which is very inconvenient for several reasons:
> 1) the meaning of the code changes depending on which file the class is in. It's very easy to accidentally expose class internal details and then call class elements that are meant to be used only inside the class. Having a keyword for class internals will allow the compiler to ensure that only the public API for the class is used from the outside world. The user can check types on his own, but it's better that the compiler does it automatically. Similarly, the user can check that only the proper APIs are called, but it's better that the compiler does it automatically.
> 2) accessibility by file structure may cause some really short files.
> 3) It's impossible to group related classes in one file but still hide implementation details inside each class
> I think that it the best solution is to make private keyword do what it states -- keep the class element private to the class. But if it's really important to have a separate keyword for backward compatibility, it would be the next best thing.
But on the flip side, with your proposed semantics for private, it would be impossible to write a group of related types, functions, and extensions that do need to refer to each other’s internal details without exposing those details to the entire module. That’s not really acceptable.
The Swift language rule encourages you to put independent definitions in different files. That definitely means that, if you want to enforce very tight separation of concerns, you’ll end up with more and smaller files. You haven’t explained why that’s really a *problem*, though.
More information about the swift-evolution