Thoughts on Swift Access Control
The proposal SE-0025: Scoped Access Level was reviewed, revised, and finally accepted for Swift 3. This proposal changed the meaning of
privateto restrict access to an entity to within the current scope or declaration, and preserved the former meaning with a new keyword,fileprivate. The hypothesis at the time was that the new (and somewhat intentionally ugly)fileprivatekeyword would rarely be used, thus abiding by Swift’s design philosophy of progressive disclosure. Little did we know that this would not be true in practice.[…]
After three controversial review periods and revisions, proposal SE-0117: Allow distinguishing between public access and public overridability was accepted for Swift 3. The proposal introduced a new access level called
openand changed the definition ofpublicin some contexts.[…]
Most recently, proposal SE-0159: Fix Private Access Levels was put forward to simply revert the changes of SE-0025. That is, remove
fileprivateand restore the original (Swift 1 and 2) semantics ofprivate. […] The newprivateessentially broke Swift’s extension-oriented style, asprivatemembers of a type were no longer accessible from anextensionon that type, even if theextensionwas declared in the same file. The proposal was reviewed with as much controversy and ferver as SE-0025 itself. […] SE-0159 was rejected, leaving the state of access control unaltered.[…]
The Core Team’s proposal that Doug outlines above is a good compromise. Before I could publish this post, David Hart opened a pull request with a draft proposal titled Type-based Private Access Level for this. I hope it gets accepted and implemented. […] The benefits of a “partly lexical and partly type-based” access control that Doug explains are clear, and I think the outweigh the drawbacks.
