> On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution > <swift-evolution@swift.org> wrote: > > 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.
+1. If we must make a change in Swift 4, the only change I can support for Swift 4 is renaming the existing access levels. That would cause some churn but can be automated and has no semantic impact. I feel strongly that the semantics of access control should remain the same until submodules and access control can be considered together as part of the theme of a larger Swift release. I believe the churn caused by continuing to poke at the semantics of access control without addressing the broader issues would be a mistake that would cause further frustration in the community. As others have already pointed out, code has been developed and organized with the new scoped access model in mind. I think the frustration over a semantically neutral, fully automated migration to new names would be pretty minimal and certainly much less than the frustration over the suggested semantic change. Renaming would restore the original intent of SE-0025 which was to leave private alone and introduce a new name for scoped access. One of the big reasons that approach was rejected is that we did not have consensus on what to call it. Now that we seem to have reached consensus about what the name should be if it is changed it is reasonable to correct the mistake that was made in Swift 3. Finally, I am not at all convinced that type-based private is the right semantics. I think the strictly hierarchical foundation of the existing access levels is a much stronger design. The suggested proposal for a same-file type-based approach has already resulted in requests for expanding that model to the whole module. Types and scopes are orthogonal dimensions. If we want to consider a hybrid model for access control I think it is best not to rush. We should take our time and consider it properly in the future. > >> On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto: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 <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
