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

Rick Mann rmann at latencyzero.com
Thu Apr 6 23:27:51 CDT 2017


> 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.

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




More information about the swift-evolution mailing list