[swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[John McCall]

> On Apr 7, 2017, at 12:48 AM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> 
>> On Apr 6, 2017, at 9:46 PM, John McCall <rjmccall at apple.com> wrote:
>> 
>>> On Apr 7, 2017, at 12:27 AM, Rick Mann <rmann at latencyzero.com> wrote:
>>>> On Apr 6, 2017, at 20:37 , John McCall <rjmccall at apple.com> wrote:
>>>> 
>>>>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> I tend to dislike the backslash as well, but can't suggest a good alternative.
>>>>> 
>>>>> Does any of this allow for operations within the key path? e.g. Department.employees. at sum.salary?
>>>> 
>>>> You can express things like this in the feature as proposed using subscripts:
>>>> 
>>>> extension Collection {
>>>> subscript<T: Integer>(summing path: KeyPath<Element, T>) -> T {
>>>> var sum: T = 0
>>>> for let elt in self {
>>>>   sum += elt[keyPath: path]
>>>> }
>>>> return sum
>>>> }
>>>> }
>>> 
>>> I'm just remembering how AppKit/Cocoa lets you do things like this in a very expressive way. Your proposal seems a bit cumbersome. Maybe when we have custom annotations, they can be extended to use within key paths.
>> 
>> I'm not seriously endorsing this exact spelling.  It would be much better to be able to write something like:
>> \Department.employees.sum(of: \.salary)
>> However, since "sum" would presumably be a method on Collection, I think this would have to be a future extension to the proposal, and the overall thing might have to be a function rather than a key path because it would no longer have identity.
> 
> Also, less clever but potentially easier to reason about:
> 
> 	extension Array where Element == Employee {
> 	  var sumOfSalary: Double {
> 		return // ...
> 	  }
> 	}
> 
> If you can express it in a computed property, you can refer to it via a key path:
> 
> 	\Department.employees.sumOfSalary

Yeah, you can, but that's definitely an expressivity hit.

John.


> 
> 
> 
>> Also, I do feel obliged to note that AppKit/Cocoa's "very expressive" way of doing this is a small number of hard-coded operators, whereas even the kindof-unfortunate subscript trick would be arbitrarily extensible.
> 
> Right.
> 
> 	- Doug
> 
>> John.
>> 
>> 
>>> 
>>> Thanks.
>>> 
>>>> 
>>>> ...
>>>> 
>>>> \Department.employees[summing: \.salary]
>>>> 
>>>> That's not actually a good name for the subscript, but maybe there's one out there.
>>>> 
>>>> John.
>>>> 
>>>>> 
>>>>> Also, in this example:
>>>>> 
>>>>> let firstFriendsNameKeyPath = \Person.friends[0].name
>>>>> let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
>>>>> 
>>>>> Can't we do without the keyPath: argument name? The compiler knows it's a keypath, it would be nicer to write
>>>>> 
>>>>> let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"
>>>>> 
>>>>>> On Apr 5, 2017, at 16:56 , Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>> 
>>>>>> Hello Swift community,
>>>>>> 
>>>>>> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:
>>>>>> 
>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>>>>>> The core team’s feedback from the first review of this proposal can be viewed at:
>>>>>> 
>>>>>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
>>>>>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>>>>>> 
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>> or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
>>>>>> 
>>>>>> Proposal link:
>>>>>> 
>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>>>>>> Reply text
>>>>>> Other replies
>>>>>> What goes into a review?
>>>>>> 
>>>>>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>>>>>> 
>>>>>> 	• What is your evaluation of the proposal?
>>>>>> 	• Is the problem being addressed significant enough to warrant a change to Swift?
>>>>>> 	• Does this proposal fit well with the feel and direction of Swift?
>>>>>> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>>>>> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>>>>> More information about the Swift evolution process is available at
>>>>>> 
>>>>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>>>>> Thank you,
>>>>>> 
>>>>>> -Doug
>>>>>> 
>>>>>> Review Manager
>>>>>> 
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Rick Mann
>>>>> rmann at latencyzero.com
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> -- 
>>> Rick Mann
>>> rmann at latencyzero.com
>>> 
>>> 
>> 
>