> On Apr 3, 2017, at 5:11 PM, David Hart via swift-evolution > <[email protected]> wrote: > >> >> On 3 Apr 2017, at 22:54, Douglas Gregor via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> On Apr 3, 2017, at 1:13 PM, Matthew Johnson <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution >>>> <[email protected] <mailto:[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… > > I still think this is a worthwhile goals. > >>> 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. > > Won’t making big modifications later be even more problematic than now, in > the name of source stability?
Yes. Big changes along these lines will not be considered later. At best, it would be possible to "re-cast" existing behaviors in light of new features — that is, significantly changing *how we talk about those behaviors*, and changing how we understand them in the broader language, but not actually changing the behaviors themselves. John. > >>> 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. >> >>> 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. >> >> - Doug >> >>> >>>> >>>>> On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution >>>>> <[email protected] <mailto:[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 >>>>> >>>>> Thoughts? Volunteer? >>>>> >>>>> - Doug >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
