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

[Xiaodi Wu]

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 <
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
> <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
> 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/20170418/bbd7f16f/attachment.html>