[43] draft update

Author: jessesquires

_drafts/2016-10-20-issue-43.md

@@ -22,9 +22,9 @@ Back in June, Austin Zheng [rewrote](https://github.com/apple/swift/pull/3046) n
 
 ### Proposals in review
 
-Ankur Patel’s proposal, [SE-0144](https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md): *Allow Single Dollar Sign as a Valid Identifier*, is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2016-October/000291.html).
+[SE-0144](https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md): *Allow Single Dollar Sign as a Valid Identifier* by Ankur Patel is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2016-October/000291.html). As discussed [last issue](/issue-42/), Ankur is the author of [Dollar.swift](https://github.com/ankurp/Dollar) which would break after a [recent fix](https://github.com/apple/swift/pull/3901) in the compiler.
 
-> The mainline Swift compiler emits an error message when the $ character (U+0024) is used as an identifier by itself, which is a source breaking change from Swift 3.0.
+> The mainline Swift compiler emits an error message when the `$` character (U+0024) is used as an identifier by itself, which is a source breaking change from Swift 3.0.
 
 {% highlight swift %}
 let $ = 10
@@ -34,11 +34,11 @@ let $ : (Int) -> (Int) = { $0 * $0 }
 class $ {}
 {% endhighlight %}
 
-> This proposal suggests reverting this change, enabling the use of $ as a valid identifier in future versions of Swift (>= 3.1).
+> This proposal suggests reverting this change, enabling the use of `$` as a valid identifier in future versions of Swift (>= 3.1).
 
 ### Mailing lists
 
-The other week, David Hart [started a discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027632.html) about `private` and `fileprivate` from [SE-0025](https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md): *Scoped Access Level*, asking if "this ship has sailed" or not. As expected, the email elicited many responses from the community. Like David and Russ, I agree that this proposal was a mistake — in practice using `fileprivate` feels cumbersome and too complex. I find extremely little value in `private`. In particular, these new access levels make type extensions more burdensome to implement since an `extension` cannot access `private` members.
+The other week, David Hart [started a discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027632.html) about `private` and `fileprivate` from [SE-0025](https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md): *Scoped Access Level*, asking if "this ship has sailed" or not. As expected, the email elicited many responses from the community. Like David and Russ, I agree that this proposal was a mistake — in practice, using `fileprivate` feels cumbersome and too complex. I find extremely little value in `private`. In particular, these new access levels make type extensions more burdensome to implement since an `extension` cannot access `private` members. If the community is willing to put forth a detailed proposal with significant evidence to support that reverting SE-0025 would be best, it sounds like the Core Team will review it. As Lattner notes below, this would require a "pretty high burden of proof." In any case, this discussion can be deferred until Spring — after Swift 4 Phase 1 is completed.
 
 From [David Hart](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027647.html):
 
@@ -78,7 +78,7 @@ From [David Hart](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-
 >
 > That said, there is no specific rush to have this discussion, and I think it is reasonable to put a pretty high burden of proof on someone who wants to drive such a proposal. For example, if we had the discussion in the spring timeframe, we should have a pretty large body of Swift 3 code readily at hand (e.g. SwiftPM packages and other various github repos).
 >
-> Given that, it should be easy enough to see how widely private is actually being used in practice. If it is very rare, then the argument to ditch it (make it a synonym for `fileprivate`, and eventually phasing out `fileprivate`) is strong. If lots of people are using `private` and only some are using `fileprivate`, then the discussion is quite different.
+> Given that, it should be easy enough to see how widely `private` is actually being used in practice. If it is very rare, then the argument to ditch it (make it a synonym for `fileprivate`, and eventually phasing out `fileprivate`) is strong. If lots of people are using `private` and only some are using `fileprivate`, then the discussion is quite different.
 
 ### Finally