[64] draft update. #204

Author: jessesquires

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

@@ -14,19 +14,15 @@ sponsor:
 
 {% include sponsor.html %}
 
-### Starter tasks
-
-> TODO
-
-{% include task_remind.html %}
-
 ### Swift Unwrapped
 
 > TODO: Latest episode of Swift Unwrapped
 
 ### News and community
 
-> TODO
+JP Simard [noticed](https://twitter.com/simjp/status/848288462952316928) references to "rename" actions in [SourceKit](https://github.com/apple/swift/tree/master/tools/SourceKit) in Xcode 8.3, and predicted we'll see refactoring support for Swift in Xcode 9. He also [pointed out](https://twitter.com/simjp/status/848288609006309376) that the "Swift Syntax Structured Editing Library" that [was announced](https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170206/004066.html) a couple of months ago is an even bigger indication of refactoring support. If true, this would be a huge relief for developers. This is something I've wanted from Xcode for years (!) now. Let's hope we see this at WWDC in a few months!
+
+Speaking of JP Simard, he released [SourceKitten 0.17.1](https://github.com/jpsim/SourceKitten/releases/tag/0.17.1), which includes Swift 3.1 support.
 
 ### Commits and pull requests
 
@@ -46,14 +42,36 @@ sponsor:
 
 ### Proposals in review
 
-[SE-0161](https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md): *Smart KeyPaths: Better Key-Value Coding for Swift* is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000334.html).
-
-> We propose a family of concrete Key Path types that represent uninvoked references to properties that can be composed to form paths through many values and directly get/set their underlying values.
+[SE-0161](https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md): *Smart KeyPaths: Better Key-Value Coding for Swift* by David Smith, Michael LeHew, and Joe Groff is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000334.html).
+
+> We propose a family of concrete _Key Path_ types that represent uninvoked references to properties that can be composed to form paths through many values and directly get/set their underlying values.
+>
+> **We Can Do Better than String**<br/>
+> On Darwin platforms Swift's existing `#keyPath()` syntax provides a convenient way to safely *refer* to properties. Unfortunately, once validated, the expression becomes a `String` which has a number of important limitations:
+>
+> * Loss of type information (requiring awkward `Any` APIs)
+> * Unnecessarily slow to parse
+> * Only applicable to `NSObjects`
+> * Limited to Darwin platforms
+>
+> **Use/Mention Distinctions**<br/>
+> While methods can be referred to without invoking them (`let x = foo.bar` instead of  `let x = foo.bar()`), this is not currently possible for properties and subscripts. Making indirect references to a properties' concrete types also lets us expose metadata about the property, and in the future additional behaviors.
+>
+> **More Expressive KeyPaths**<br/>
+> We would also like to support being able to use _Key Paths_ to access into collections, which is not currently possible.
+
+[SE-0155](https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md): *Normalize Enum Case Representation* by Daniel Duan and Joe Groff is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000336.html).
+
+> In Swift 3, associated values of an enum case are represented by a tuple. This implementation causes inconsistencies in case declaration, construction and pattern matching in several places.
+>
+> Enums, therefore, can be made more "regular" when we replace tuple as the representation of associated case values. This proposal aims to define the effect of doings so on various parts of the language.
+>
+> Swift-evolution thread: [Normalize Enum Case Representation (rev. 2)](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170306/033626.html)
 
 ### Mailing lists
 
 > TODO
 
 ### Finally
 
-> TODO: something funny/fun. tweet, link, etc.
+And finally &mdash; the `isn't` [operator](https://twitter.com/harlanhaskins/status/848172027760574465). 😂