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?
- Doug_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
