Thursday, April 6, 2017

Thoughts on Swift Access Control

Jesse Squires (tweet):

The proposal SE-0025: Scoped Access Level was reviewed, revised, and finally accepted for Swift 3. This proposal changed the meaning of private to 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) fileprivate keyword 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 open and changed the definition of public in 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 fileprivate and restore the original (Swift 1 and 2) semantics of private. […] The new private essentially broke Swift’s extension-oriented style, as private members of a type were no longer accessible from an extension on that type, even if the extension was 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.

Comments RSS · Twitter

Leave a Comment