> On Apr 7, 2017, at 12:48 AM, Douglas Gregor <[email protected]> wrote: > > >> On Apr 6, 2017, at 9:46 PM, John McCall <[email protected]> wrote: >> >>> On Apr 7, 2017, at 12:27 AM, Rick Mann <[email protected]> wrote: >>>> On Apr 6, 2017, at 20:37 , John McCall <[email protected]> wrote: >>>> >>>>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution >>>>> <[email protected]> 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. >>>>> [email protected]? >>>> >>>> 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 >>>>>> <[email protected]> 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 >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> >>>>> -- >>>>> Rick Mann >>>>> [email protected] >>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> -- >>> Rick Mann >>> [email protected] >>> >>> >> > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
