Extremely happy to see this outcome. Thank you Core Team for dealing with the seemingly never-ending arguments about access control, hopefully the majority of that is behind us now :^)
> On Apr 17, 2017, at 5:25 PM, 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 was introduced) and during Swift 4 (including > SE-0159 and other proposals). 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 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.swift > struct A { > private var aMember : Int > } > > // FileB.swift > extension 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
