[swift-evolution] Type-based ‘private’ access within a file

[Charles Srstka]

> On Apr 3, 2017, at 1:34 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Swift Community,
> 
> In rejecting SE-0159 <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md>, the core team described a potential direction we would like to investigate for “private” access control that admits a limited form of type-based access control within files. The core team is seeking some discussion here and a motivated volunteer to put together a proposal along these lines for review in the Swift 4 time-frame (i.e., very soon). To be clear, the core team it’s sure this is the right direction to go… but it appears promising and we would *love* to be able to settle the access-control issue.
> 
> The design, specifically, is that a “private” member declared within a type “X” or an extension thereof would be accessible from:
> 
> 	* An extension of “X” in the same file
> 	* The definition of “X”, if it occurs in the same file
> 	* A nested type (or extension thereof) of one of the above that occurs in the same file
> 
> This design has a number of apparent benefits:
> 	+ “private” becomes the right default for “less than whole module” visibility, and aligns well with Swift coding style that divides a type’s definition into a number of extensions.
> 	+ “fileprivate” remains for existing use cases, but now it’s use it more rare, which has several advantages:
> 		+ It fits well with the "progressive disclosure” philosophy behind Swift: you can use public/internal/private for a while before encountering and having to learn about “fileprivate”   (note: we thought this was going to be true of SE-0025 <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>, but we were clearly wrong)
> 		+ When “fileprivate” occurs, it means there’s some interesting coupling between different types in the same file. That makes fileprivate a useful alert to the reader rather than, potentially, something that we routinely use and overlook so that we can separate implementations into extensions.
> 	+ “private” is more closely aligned with other programming languages that use type-based access control, which can help programmers just coming to Swift. When they reach for “private”, they’re likely to get something similar to what they expect—with a little Swift twist due to Swift’s heavy use of extensions.
> 	+ Loosening the access restrictions on “private” is unlikely to break existing code.
> 
> There are likely some drawbacks:
> 	- Developers using patterns that depend on the existing lexically-scoped access control of “private” may find this new interpretation of “private” to be insufficiently strict
> 	- Swift’s access control would go from “entirely lexical” to “partly lexical and partly type-based”, which can be viewed as being more complicated
> 
> Thoughts? Volunteer?

This appears similar to an idea I brought up during the SE-0159 discussion:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034156.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034156.html>
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034162.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034162.html>

I feel that, while imperfect, the idea would provide a compromise between those of us who prefer to have a scoped access level, and those who feel encumbered by ‘private’ not applying to in-file extensions. Therefore, I’d be generally +1 on it.

Charles

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