The review of ran from March 20...27, 2017. The proposal has been *rejected*.
The core team had a lengthy discussion of this proposal as well as related ideas that came up during (and prior to) the review [*].
SE-0159 <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md> specifically sought to revert the main user-facing part of SE-0025 <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>, which gave “private” lexical-scoping semantics and introduced “fileprivate”. The core team felt that there was sufficient evidence that more-restrictive-than-fileprivate access control is in use within the Swift community and in established patterns, such that it would be harmful to remove the functionality introduced by SE-0025 <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md> at this point.
The core team discussed the idea of renaming to keywords that was brought up in the thread as a way to address many of the concerns raised in SE-0159 <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md> while providing the same language semantics. Specifically:
* “private” -> “scoped”
* “fileprivate” -> “private”
The core team determined that such a change, while (technically) easy to automatically migrate, would introduce far too much churn in Swift code bases moving from Swift 3 to Swift 4, compromising the source stability goals set out for Swift 4.
Finally, the core team discussed a different potential design for “private” that admits a limited form of type-based access control within files. We will open a separate discussion thread on Swift Evolution, with the subject "Type-based ‘private’ access within a file", and are seeking further discussion there and a motivated volunteer to turn it into a new proposal for Swift 4.
- Doug Gregor
[*] Big thanks to Alex Martini for his excellent notes.