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

[Douglas Gregor]

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md <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.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170417/beeec3a5/attachment-0001.html>