drafts

Author: jessesquires

_drafts/2016-04-21-issue-19.md

@@ -63,9 +63,23 @@ David Hart's proposal, [SE-0062](https://github.com/apple/swift-evolution/blob/m
 
 > The proposal is accepted, with one adjustment to the handling of collections: rather than support any SequenceType as a collection, the core team wants a narrower rule for only the primary Cocoa collection types (`NSArray`, `NSDictionary`, `NSSet`) and their Swift-bridged equivalents (`Array`, `Dictionary`, `Set`), due to implementation concerns. Feedback on this proposal was generally positive, and the proposal fits well with `#selector` ([SE-0022](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md)).
 
+David Hart's proposal, [SE-0064](https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md): *Referencing the Objective-C selector of property getters and setters*, has been [accepted](https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000102.html) **for Swift 3**. *"Feedback was light but positive, with many considering this to effectively be an obviously-missing piece of the `#selector` proposal [SE-0022](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md)."* Work is being tracked at [SR-1239](https://bugs.swift.org/browse/SR-1239). Alex Hoppen is working on an implementation.
+
+Max Howell's proposal, [SE-0063](https://github.com/apple/swift-evolution/blob/master/proposals/0063-swiftpm-system-module-search-paths.md): *SwiftPM System Module Search Paths*, has been [accepted](https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000104.html) **for Swift 3**. *"Feedback was light but positive, which was not surprising since there had been email discussions of this topic for some time and there was general agreement about the need."*
+
+Dave Abrahams' proposal, [SE-0059](https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md): *Update API Naming Guidelines and Rewrite `Set` APIs Accordingly*, has been [accepted](https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000105.html) **for Swift 3**.
+
+>There was much debate, both before and during the review, over the “InPlace” suffix / “form” prefix, and at this point any answer will be objectionable to some. The core team has opted to accept the proposal as-is, keeping the “form” prefix to describe the mutating counterpart to an operation naturally described by a noun (e.g., “formUnion” for the mutating variant of “union”), for the reasons described in the proposal itself. Thanks all for the spirited discussion!
+
 ### Proposals in review
 
-> TODO
+Stephen Canon's proposal, [SE-0067](https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md): *Enhanced Floating Point Protocols*, is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000106.html).
+
+>The current `FloatingPoint` protocol is quite limited, and provides only a small subset of the features expected of an IEEE 754 conforming type. This proposal expands the protocol to cover most of the expected basic operations, and adds a second protocol, `BinaryFloatingPoint`, that provides a number of useful tools for generic programming with the most commonly used types.
+
+Erica Sadun's proposal, [SE-0068](https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md): *Expanding Swift `Self` to class members and value types*, is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000107.html).
+
+>Within a class scope, `Self` means "the dynamic class of self". This proposal extends that courtesy to value types and to the bodies of class members by renaming `dynamicType` to `Self`. This establishes a universal and consistent way to refer to the dynamic type of the current receiver.
 
 ### Mailing lists