I’m concerned that we will have access control changes in a future version yet again, when light-weight modules, or other type of enforced namespace is introduced. Does the core team have any foresight on how this change would interact with such things? I had the same concern for SE-0159 as well.
There’s a implicit drawback to all access control changes that migrator/fix-its cannot fix: we organize our code with tools in the language. Some colleague of mine had came up with schemes that combines file scope and Swift 3 `private` to hide details among separate protocol extensions, for example. Code ends up in certain places for a reason and updating access control invalidate those reasons. I hesitate to support any changes until we have some ideas for what “ultimate glory” looks like. > On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution > <swift-evolution@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? > > - Doug > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
