[swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Riley Testut]

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 <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170417/33599794/attachment.html>