> On Apr 3, 2017, at 3:54 PM, Douglas Gregor <dgre...@apple.com> wrote: > > >> On Apr 3, 2017, at 1:13 PM, Matthew Johnson <matt...@anandabits.com >> <mailto:matt...@anandabits.com>> wrote: >> >>> >>> On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution >>> <swift-evolution@swift.org <mailto: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. > > We don’t have to make a change in Swift 4. If there’s a change that can > resolve this issue, great… > >> 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. > > … but if not, then let’s shelve access control changes until some time when > we can considered it holistically with something like submodules, as you note > above.
This is certainly what I would prefer. I only mention renaming because there is such strong interest in changing something. I would be happy to defer this topic and have been arguing for that approach ever since your note that only SE-0159 would be considered in scope for Swift 4. > >> 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 > > The core team felt strongly that we couldn’t change these keywords. Source > stability is important to Swift 4, and “don’t break source compatibility so > much” is one of the top requests we hear from Swift developers, much more so > than requests for specific new language features. That’s fair. > >> and certainly much less than the frustration over the suggested semantic >> change. > > This isn’t clear to me. There could certainly be frustration over the > suggested semantic change, for a number of reasons: > > * It’s not as “tight” a meaning of private as the current scope-based private. > * It means we have a hybrid type-based/scope-based model. > * It’s the third meaning of ‘private’ in three years. > > However, it is unlikely to break code (one would need to construct an > ambiguity between two private declarations in different extensions of the > same type in the same file), and causes zero code churn, because it’s > widening the meaning of “private”, not changing it. I’m speculating based on my read of the community here as well as other Swift developers I know. I could be wrong, but my sense is that the items you list would cause more frustration than renaming, especially if the name change purged `fileprivate`. I don’t know anyone outside the evolution community who I think would complain if access control was left alone for a while. Some were not happy with the changes in Swift 3 but I don’t hear too much about it off the list anymore now that the migration is over and people have adapted. > > - Doug > >> >>> >>>> 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 >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
