[64] draft update. #204

Author: jessesquires

_drafts/2017-04-06-issue-64.md

@@ -8,7 +8,7 @@ sponsor:
     body: Dave Verwer from iOS Dev Weekly here. I'm a big fan of the Swift Weekly Brief so when I saw they were looking for support, I thought I should do that! Keep up the good work Jesse!
 ---
 
-> TODO: intro comments
+The great access control ~~battle~~ debate is finally over! Yet, the ~~holy war~~ discussion is not quite over.
 
 <!--excerpt-->
 
@@ -30,17 +30,22 @@ Speaking of JP Simard, he released [SourceKitten 0.17.1](https://github.com/jpsi
 
 > TODO
 
-### Accepted proposals
-
-> TODO
-
-### Returned proposals
-
-> TODO
-
 ### Rejected proposals
 
-> TODO
+[SE-0159](https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md): *Fix Private Access Levels* was [rejected](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000337.html).
+
+> 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.
 
 ### Proposals in review
 
@@ -72,7 +77,29 @@ Speaking of JP Simard, he released [SourceKitten 0.17.1](https://github.com/jpsi
 
 ### Mailing lists
 
-> TODO
+As mentioned above in the rejection of SE-0159, Doug Gregor has [opened a new discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034903.html) about implementing type-based 'private' access within a file &mdash; which will hopefully settle Swift's access control story for good.
+
+> In rejecting [SE-0159](https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md), the core team described a potential direction we would like to investigate for “private” access control that admits a limited form of type-based access control within files. The core team is seeking some discussion here and a motivated volunteer to put together a proposal along these lines for review in the Swift 4 time-frame (i.e., very soon). To be clear, the core team isn't sure this is the right direction to go... but it appears promising and we would *love* to be able to settle the access-control issue.
+>
+> The design, specifically, is that a “private” member declared within a type “X” or an extension thereof would be accessible from:
+>
+> * An extension of “X” in the same file
+> * The definition of “X”, if it occurs in the same file
+> * A nested type (or extension thereof) of one of the above that occurs in the same file
+>
+> This design has a number of apparent benefits:
+> * `private` becomes the right default for "less than whole module" visibility, and aligns well with Swift coding style that divides a type’s definition into a number of extensions.
+> * `fileprivate` remains for existing use cases, but now it’s use it more rare, which has several advantages:
+>   * It fits well with the "progressive disclosure" philosophy behind Swift: you can use `public`/`internal`/`private` for a while before encountering and having to learn about `fileprivate` (note: we thought this was going to be true of [SE-0025](https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md), but we were clearly wrong)
+>   * When `fileprivate` occurs, it means there’s some interesting coupling between different types in the same file. That makes `fileprivate` a useful alert to the reader rather than, potentially, something that we routinely use and overlook so that we can separate implementations into extensions.
+> * `private` is more closely aligned with other programming languages that use type-based access control, which can help programmers just coming to Swift. When they reach for `private`, they’re likely to get something similar to what they expect—with a little Swift twist due to Swift’s heavy use of extensions.
+> * Loosening the access restrictions on `private` is unlikely to break existing code.
+>
+> There are likely some drawbacks:
+> * Developers using patterns that depend on the existing lexically-scoped access control of `private` may find this new interpretation of `private` to be insufficiently strict
+> * Swift’s access control would go from "entirely lexical" to "partly lexical and partly type-based", which can be viewed as being more complicated
+>
+> Thoughts? Volunteer?
 
 ### Finally