drafts

Author: jessesquires

_drafts/2016-04-14-issue-18.md

@@ -52,9 +52,26 @@ Manav Gabhawala opened a [pull request](https://github.com/apple/swift/pull/2123
 
 > TODO
 
+### Deferred proposals
+
+Russ Bishop's and Doug Gregor's proposal, [SE-0058](https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md): *Allow Swift types to provide custom Objective-C representations* has been [**deferred**](https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000095.html) from Swift 3. Joe Groff explains that it is simply too early to commit to a public API for this. Interestingly, he mentions the idea of bridging with JVM in the future... 🤔 🤐
+
+>We agree that it would be valuable to give library authors the ability to bridge their own types from Objective-C into Swift using the same mechanisms as Foundation. However, we lack the confidence and implementation experience to commit to `_ObjectiveCBridgeable` in its current form as public API. In its current form, as its name suggests, the protocol was designed to accommodate the specific needs of bridging Objective-C object types to Swift value types. In the future, we may want to bridge with other platforms, including C++ value types or other object systems such as COM, GObject, JVM, or CLR. It isn't clear at this point whether these would be served by a generalization of the existing mechanism, or by bespoke bridging protocols tailored to each case. This is a valuable area to explore, but we feel that it is too early at this point to accept our current design as public API.
+
 ### Proposals in review
 
-> TODO
+David Hart's proposal, [SE-0062](https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md): *Referencing Objective-C key-paths*, is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000091.html). *"In Objective-C and Swift, key-paths used by KVC and KVO are represented as string literals. This proposal seeks to improve the safety and resilience to modification of code using key-paths by introducing a compiler-checked expression."*
+
+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*, is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000092.html). *"Proposal [SE-0022](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) was accepted and implemented to provide a #selector expression to reference Objective-C method selectors. Unfortunately, it does not allow referencing the getter and setter methods of properties. This proposal seeks to provide a design to reference those methods for the Swift 3.0 timeframe."*
+
+A proposal from Dmitri Gribenko, Dave Abrahams, and Maxim Moiseev, [SE-0065](https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md): *A New Model for Collections and Indices* is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000094.html).
+
+>We propose a new model for `Collection`s wherein responsibility for index traversal is moved from the index to the collection itself. For example, instead of writing `i.successor()`, one would write `c.successor(of: i)`. We also propose the following changes as a consequence of the new model:
+>
+> - A collection's Index can be any `Comparable` type.
+> - The distinction between intervals and ranges disappears, leaving only ranges.
+> - A closed range that includes the maximal value of its `Bound` type is now representable and does not trap.
+> - Existing “private” in-place index traversal methods are now available publicly.
 
 ### Mailing lists