> On Apr 7, 2017, at 1:40 PM, Joe Groff <[email protected]> wrote: >> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution >> <[email protected]> wrote: >> >>> >>> 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. > > True, but there are some benefits to requiring a subscript/property rather > than an arbitrary closure, particularly that it gives the operation a stable > identity and structure so the key path can still be equated/hashed and > (eventually) iterated through.
Right, I think if you add a method to the chain, the result definitely has to be a function rather than a key path. The idea is that you basically decompose: \Base.A.B.C into ([inout]? Base, parameters(A)..., parameters(B)..., parameters(C)...) -> result(C) except that if all of the components A, B, and C are just properties or applied subscripts you can make it a KeyPath<Base,C> instead, which can then contextually devolve into a function. John. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
