I'm broadly in favor of this. On Mon, Apr 3, 2017 at 2:35 PM Douglas Gregor via swift-evolution < [email protected]> 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 > I think it might not as complicated as it may first appear. I haven't fully convinced myself of this, but I believe that it would be lexically scoped *modulo inlining extensions*. To put it somewhat more formally (and awkwardly), if one imagines a textual transformation which blindly inlines any extension in a single file into their type definitions (should those definitions occur within that file) then accessing a "private" member in the original file would compile if and only if the access would be lexically scoped if the above postulated transformation were to be applied to it. This is a pleasing property (to me anyway) as it means that it is unlikely (impossible?) for moving code from one extension (or definition) to another to cause a compilation failure. Take this with a grain of salt of course, as there's probably an edge case I'm not thinking of :P (This is why we write proofs!) Cheers, -Colin > Thoughts? Volunteer? > > - Doug > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
