Sent from my iPhone > On 4 Apr 2017, at 03:20, Shawn Erickson via swift-evolution > <[email protected]> wrote: > > Yeah I think the best course of action is to leave things alone until such > time as we can more holistically work things as you outline.
Considering how small this private rule relaxation is, it seems strange to swat away this proposal... (especially from the perspective which did want to reverse the previous proposal if I have to be honest). I am not seeing why we should wait. > > Folks can strive to use private as the default lesser then module access > level with fileprivate remaining available for those code patterns that > require it for now (e.g. falling back on using the IMHO crutch of file > co-residency). > >> On Mon, Apr 3, 2017 at 1:28 PM Austin Zheng via swift-evolution >> <[email protected]> wrote: >> I am a reluctant -1. If rejecting 159 was the right course of action to >> avoid unnecessary churn, I think that any further modification to the access >> control system should come as part of a comprehensive >> modules/namespaces/code organization proposal. Extracting a bit of >> progressive disclosure from yet another change in the rules really doesn’t >> seem worth the cost of developers having to relearn what access control does >> yet again. >> >> Best, >> Austin >> >> >>> On Apr 3, 2017, at 2:34 PM, 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
