Does the acceptance of SE-0169 imply any change to rules for `private extension` members, or does the core team intend such members to continue defaulting to fileprivate visibility?
On Mon, Apr 17, 2017 at 19:25 Douglas Gregor via swift-evolution < [email protected]> wrote: > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md > > Hello Swift Community, > > The review of SE-0169 "Improve Interaction Between `private` Declarations > and Extensions” ran from April 6...11, 2017. The proposal is *accepted*. > > This topic has been highly controversial for a long time, both during > Swift 3’s development (when SE-0025 > <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md> > was > introduced) and during Swift 4 (including SE-0159 > <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md> > and other <https://github.com/apple/swift-evolution/pull/680> proposals > <https://github.com/apple/swift-evolution/pull/681>). There is no > solution that will make everyone happy: maintaining the status quo makes > “fileprivate” too common and therefore not meaningful when it occurs in > source; removing or diluting scope-level access control (as in SE-0159 > <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md> > and > this proposal) takes away a tool that is in use by Swift developers; and > adding more levels of access control complicates the language. > > The core team feels that this proposal makes private access align more > closely with the goals of the language: > > > - It supports the notion that extensions are a code-organization tool: > one should be able to break up a type’s definition into several extensions > to improve the clarity of that code, without having to open up access or > otherwise view the members in different extensions as completely-distinct > entities. The core team expects future language evolution to reinforce the > notion that extensions are more of a code organization tool than distinct > entities, e.g., allowing stored properties to be introduced in an > extension. > - It makes private more usable as the default sub-internal access > level, which supports progressive disclosure of the access control system > and better matches with programmer’s expectations about what private > access means. > - It makes fileprivate more meaningful, because it is only needed for > those cases where one is reaching across types (or among types and globals) > within a file. It will also become more rare, which matches well with its > longer, descriptive name. > > > The proposal’s acceptance includes one modification: extensions of a given > type that reside in a single file that is different from the file that > defines the type itself will have access to the private members of all > other extensions in that file. For example: > > // FileA.swiftstruct A { > private var aMember : Int > } > // FileB.swiftextension A { > private func foo() { > bar() // ok, foo() does have access to bar() } > } > extension A { > private func bar() { > aMember = 42 // not ok, private members may not be accessed outside > their file. } > } > > > The proposal has already been updated to reflect this change, which better > reflects the notion that extensions are a code-organization tool. > > The core team considers the access-control matter closed for Swift 4 and > will not be reviewing any further proposals in this area. > > - Doug > Review Manager > _______________________________________________ > 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
