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@swift.org> wrote:
Proposal Link:
https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.mdHello 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution