Expanding Swift Self to class members and value types

0000-template.md

@@ -2,7 +2,7 @@
 
 * Proposal: [SE-NNNN](https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md)
 * Author(s): [Swift Developer](https://github.com/swiftdev)
-* Status: **Awaiting review**
+* Status: **[Awaiting review](#rationale)**
 * Review manager: TBD
 
 ## Introduction
@@ -50,3 +50,10 @@ automatically?
 Describe alternative approaches to addressing the same problem, and
 why you chose this approach instead.
 
+-------------------------------------------------------------------------------
+
+# Rationale
+
+On Smarch 13, 20XX, the core team decided to **(TBD)** this proposal.
+When the core team makes a decision regarding this proposal,
+their rationale for the decision will be written here.

README.md

@@ -112,6 +112,7 @@ sampling of potentially good ideas that are not in scope for Swift
 * [SE-0037: Clarify interaction between comments & operators](proposals/0037-clarify-comments-and-operators.md)
 * [SE-0040: Replacing Equal Signs with Colons For Attribute Arguments](proposals/0040-attributecolons.md)
 * [SE-0043: Declare variables in 'case' labels with multiple patterns](proposals/0043-declare-variables-in-case-labels-with-multiple-patterns.md)
+* [SE-0046: Establish consistent label behavior across all parameters including first labels](proposals/0046-first-label.md)
 * [SE-0053: Remove explicit use of `let` from Function Parameters](proposals/0053-remove-let-from-function-parameters.md)
 
 ### Accepted proposals for Swift 3.0
@@ -127,7 +128,6 @@ sampling of potentially good ideas that are not in scope for Swift
 * [SE-0039: Modernizing Playground Literals](proposals/0039-playgroundliterals.md)
 * [SE-0042: Flattening the function type of unapplied method references](proposals/0042-flatten-method-types.md)
 * [SE-0044: Import as Member](proposals/0044-import-as-member.md)
-* [SE-0046: Establish consistent label behavior across all parameters including first labels](proposals/0046-first-label.md)
 * [SE-0047: Defaulting non-Void functions so they warn on unused results](proposals/0047-nonvoid-warn.md)
 * [SE-0054: Abolish `ImplicitlyUnwrappedOptional` type](proposals/0054-abolish-iuo.md)
 * [SE-0055: Make unsafe pointer nullability explicit using Optional](proposals/0055-optional-unsafe-pointers.md)
@@ -180,3 +180,4 @@ sooner.
 ### Deferred for Future Discussion
 
 * [SE-0026: Abstract classes and methods](proposals/0026-abstract-classes-and-methods.md)
+* [SE-0058: Allow Swift types to provide custom Objective-C representations](proposals/0058-objectivecbridgeable.md)

proposals/0009-require-self-for-accessing-instance-members.md

@@ -9,6 +9,8 @@
 
 The current version of Swift (2.1) requires using `self` when accessing instance members in closures. The proposal suggests extending this to all member accesses (as is intrinsically the case in Objective-C). It has the benefit of documenting instance properties vs local variables and instance functions vs local functions or closures.
 
+[Swift Evolution Discussion Thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/9526)
+
 ## Motivation
 
 This proposal makes it obvious which are instance properties vs local variables, as well as which are instance functions vs local functions/closures. This has several advantages:

proposals/0010-add-staticstring-unicodescalarview.md

@@ -10,6 +10,8 @@
 There is no way to create a substring of a `StaticString` that is still typed
 as `StaticString`. There should be.
 
+[Swift Evolution Discussion Thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/9366), [Review](http://thread.gmane.org/gmane.comp.lang.swift.evolution/2434)
+
 ## Motivation
 
 It is occasionally useful to be able to produce a substring of a `StaticString`

proposals/0011-replace-typealias-associated.md

@@ -18,6 +18,8 @@ confusion surrounding the use of associated types.
 
 The proposed new keyword is `associatedtype`.
 
+[Swift Evolution Discussion Thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/9301)
+
 ## Motivation
 
 Re-using `typealias` for associated type declarations is confusing in many ways.

proposals/0012-add-noescape-to-public-library-api.md

@@ -17,6 +17,8 @@
 *  We propose exposing this attribute in CF and Foundation as `CF_NOESCAPE` and `NS_NOESCAPE`
 *  We also propose applying this declaration to a number of closure-taking APIs in CF and Foundation 
 
+[Swift Evolution Discussion Thread](http://thread.gmane.org/gmane.comp.lang.swift.corelibs/53)
+
 ## Introduction
 
 ### `@noescape`

proposals/0013-remove-partial-application-super.md

@@ -22,6 +22,8 @@ those mechanisms, I propose that we disallow partial application of
 non-final methods through `super`, except where the `self` parameter is
 implicitly captured.
 
+[Swift Evolution Discussion Thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/9778), [Review](http://thread.gmane.org/gmane.comp.lang.swift.evolution/2880)
+
 ## Motivation
 
 The motivation of this change is partially motivated by implementation

proposals/0014-constrained-AnySequence.md

@@ -10,6 +10,8 @@
 In order to allow `AnySequence` delegate calls to the underlying sequence,
 its initializer should have extra constraints.
 
+[Swift Evolution Discussion](http://thread.gmane.org/gmane.comp.lang.swift.evolution/1893)
+
 ## Motivation
 
 At the moment `AnySequence` does not delegate calls to `SequenceType` protocol

proposals/0015-tuple-comparison-operators.md

@@ -9,6 +9,10 @@
 
 Implement comparison operators on tuples up to some arity.
 
+[Initial Discussion](http://article.gmane.org/gmane.comp.lang.swift.evolution/980/match=tuple+comparison), [General Discussion](http://thread.gmane.org/gmane.comp.lang.swift.evolution/9723), [Review](http://thread.gmane.org/gmane.comp.lang.swift.evolution/11423/focus=732)
+
+Note: The review was initially started on the wrong thread with the wrong title and subsequently corrected.
+
 ## Motivation
 
 It's annoying to try and compare tuples of comparable values and discover that

proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md

@@ -13,6 +13,8 @@ allow users to call C functions with `intptr_t` and `uintptr_t` parameters, and
 allow users to perform more advanced pointer arithmetic than is allowed by
 `UnsafePointer`s.
 
+[Swift Evolution Discussion](http://thread.gmane.org/gmane.comp.lang.swift.evolution/10044), [Review](http://thread.gmane.org/gmane.comp.lang.swift.evolution/12696)
+
 ## Motivation
 ## 
 Swift currently lacks the ability to perform many complex operations on

proposals/0017-convert-unmanaged-to-use-unsafepointer.md

@@ -9,6 +9,8 @@
 
 The standard library [`Unmanaged<Instance>` struct](https://github.com/apple/swift/blob/master/stdlib/public/core/Unmanaged.swift) provides a type-safe object wrapper that does not participate in ARC; it allows the user to make manual retain/release calls.
 
+[Swift Evolution Discussion](http://thread.gmane.org/gmane.comp.lang.swift.evolution/9877), [Proposed Rewrite Discussion](http://thread.gmane.org/gmane.comp.lang.swift.evolution/68/)
+
 ## Motivation
 
 The following methods are provided for converting to/from Unmanaged:

proposals/0019-package-manager-testing.md

@@ -13,6 +13,8 @@ Testing is an essential part of modern software development.
 Tight integration of testing into the Swift Package Manager
 will help ensure a stable and reliable packaging ecosystem.
 
+[SE Review Link](http://thread.gmane.org/gmane.comp.lang.swift.evolution/3583)
+
 ## Proposed Solution
 
 We propose to extend our conventional package directory layout

proposals/0058-objectivecbridgeable.md

@@ -2,7 +2,7 @@
 
 * Proposal: SE-0058
 * Author(s): [Russ Bishop](https://github.com/russbishop), [Doug Gregor](https://github.com/DougGregor)
-* Status: **Review**
+* Status: **[Deferred](#rationale)**
 * Review manager: [Joe Groff](https://github.com/jckarter)
 
 
@@ -243,3 +243,22 @@ This can always be implemented in the future if it is desired.
 
 It is intended that when and if Swift 3 adopts conditional protocol conformance that the standard library types such as `Array` and `Dictionary` will declare conditional conformance to `ObjectiveCBridgeable` if their element types are `ObjectiveCBridgeable` (with explicitly declared conformance for built-ins like `Int`).
 
+-------------------------------------------------------------------------------
+
+# Rationale
+
+On April 12, 2016, the core team decided to **defer** this proposal from
+Swift 3. 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/0062-objc-keypaths.md

@@ -0,0 +1,86 @@
+# Referencing Objective-C key-paths
+
+* Proposal: [SE-0062](https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md)
+* Author(s): [David Hart](https://github.com/hartbit)
+* Status: **Under review** (April 7...12, 2016)
+* Review manager: [Doug Gregor](https://github.com/DougGregor)
+
+## Introduction
+
+In Objective-C and Swift, key-paths used by KVC and KVO are represented as string literals (e.g., `"friend.address.streetName"`). This proposal seeks to improve the safety and resilience to modification of code using key-paths by introducing a compiler-checked expression.
+
+## Motivation
+
+The use of string literals for key paths is extremely error-prone: there is no compile-time assurance that the string corresponds to a valid key-path. In a similar manner to the proposal for the Objective-C selector expression [SE-0022](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md), this proposal introduces syntax for referencing compiler-checked key-paths. When the referenced properties and methods are renamed or deleted, the programmer will be notified by a compiler error.
+
+## Proposed solution
+
+Introduce a new expression `#keyPath()` that allows one to build a compile-time valid key-path string literal (to allow it be used as `StaticString` and `StringLiteralConvertible`):
+
+```swift
+class Person: NSObject {
+	dynamic var firstName: String = ""
+	dynamic var lastName: String = ""
+	dynamic var friends: [Person] = []
+	dynamic var bestFriend: Person?
+
+	init(firstName: String, lastName: String) {
+		self.firstName = firstName
+		self.lastName = lastName
+	}
+}
+
+let chris = Person(firstName: "Chris", lastName: "Lattner")
+let joe = Person(firstName: "Joe", lastName: "Groff")
+let douglas = Person(firstName: "Douglas", lastName: "Gregor")
+chris.friends = [joe, douglas]
+chris.bestFriend = joe
+
+
+#keyPath(Person.firstName) // => "firstName"
+chris.valueForKey(#keyPath(Person.firstName)) // => Chris
+#keyPath(Person.bestFriend.lastName) // => "bestFriend.lastName"
+chris.valueForKeyPath(#keyPath(Person.bestFriend.lastName)) // => Groff
+#keyPath(Person.friends.firstName) // => "friends.firstName"
+chris.valueForKeyPath(#keyPath(Person.friends.firstName)) // => ["Joe", "Douglas"]
+```
+
+By having the `#keyPath` expression do the work to form the Objective-C key-path string, we free the developer from having to do the manual typing and get static checking that the key-path exists and is exposed to Objective-C.
+
+It would also be very convenient for the `#keyPath` to accept value (instead of static) expressions:
+
+```
+extension Person {
+	class func find(name: String) -> [Person] {
+		return DB.execute("SELECT * FROM Person WHERE \(#keyPath(firstName)) LIKE '%\(name)%'")
+	}
+}
+```
+
+In this case, `#keyPath(firstName)` is understood to represent `#keyPath(Person.firstName)`.
+
+## Collection Keypaths
+
+As Foundation types are not strongly-typed, the key-path expression should only accept traversing `SequenceType` conforming types:
+
+```swift
+let swiftArray = ["Chris", "Joe", "Douglas"]
+let nsArray = NSArray(array: swiftArray)
+swiftArray.valueForKeyPath(#keyPath(swiftArray.count)) // => 3
+swiftArray.valueForKeyPath(#keyPath(swiftArray.uppercased)) // => ["CHRIS", "JOE", "DOUGLAS"]
+swiftArray.valueForKeyPath(#keyPath(nsArray.count)) // => 3
+swiftArray.valueForKeyPath(#keyPath(nsArray.uppercaseString)) // compiler error
+```
+There is some implicit bridging going on here that could use some detailed design. If I refer to `Person.lastName.uppercased`, that's a method on the value type `String`. At runtime, we're depending on getting the `uppercaseString` method on `NSString`. This may be as simple as saying that we follow the `_ObjectiveCBridgeable` conformance for any value type encountered along the way.
+
+## Collection Operators
+
+This proposal purposely does not attempt to implement Collection Operators as the current functionality stands on its own and is useful even without the Objective-C runtime (as can be seen in the previous example). On the contrary, collection operators will require more design, and are only useable with `valueForKeyPath:` which is not available on Linux.
+
+## Impact on existing code
+
+The introduction of the `#keyPath` expression has no impact on existing code, and is simply a modification-safe alternative to using strings literal for referencing key-paths.
+
+## Alternatives considered
+
+There does not seem to be any obvious alternatives. The only point of discussion was on the name of the expression. `#key` was proposed: it is shorter but does not seem to express that the expression accepts paths.