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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
