Sent from my iPhone > On 3 Apr 2017, at 22:03, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > >>> On Apr 3, 2017, at 3:54 PM, Douglas Gregor <[email protected]> wrote: >>> >>> >>>> On Apr 3, 2017, at 1:13 PM, Matthew Johnson <[email protected]> wrote: >>>> >>>> >>>> On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution >>>> <[email protected]> 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.
I would quite like the model proposed here actually as it does make private a very very sane default, fits with Swift's progressive disclosure goals and its architecture, as well as eases the transition of developers from other major languages which is a massive boon to this community too without nasty side effects or sacrifices to Swift's ideals. +1 to this change :). I think this proposal is worth acting upon rather than waiting another year for something which, looking ahead, is not sure to be overhauled so much before Swift 5 is finalised. > 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 >>>>> <[email protected]> wrote: >>>>> >>>>> Hello Swift Community, >>>>> >>>>> In rejecting SE-0159, 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, 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 >>>> >>>> _______________________________________________ >>>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
