> On Apr 7, 2017, at 2:50 PM, Joe Groff <jgr...@apple.com> wrote: >> On Apr 7, 2017, at 11:48 AM, John McCall <rjmcc...@apple.com> wrote: >> >>> On Apr 7, 2017, at 1:40 PM, Joe Groff <jgr...@apple.com> wrote: >>>> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>>> >>>>> On Apr 7, 2017, at 12:48 AM, Douglas Gregor <dgre...@apple.com> wrote: >>>>> >>>>> >>>>>> On Apr 6, 2017, at 9:46 PM, John McCall <rjmcc...@apple.com> wrote: >>>>>> >>>>>>> On Apr 7, 2017, at 12:27 AM, Rick Mann <rm...@latencyzero.com> wrote: >>>>>>>> On Apr 6, 2017, at 20:37 , John McCall <rjmcc...@apple.com> wrote: >>>>>>>> >>>>>>>>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution >>>>>>>>> <swift-evolution@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.@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. >>> >>> 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. > > It seems to me that method references (non-mutating ones, at least) could > still be treated as read-only key path components. There's not much more than > syntax as a difference between a nonmutating method and get-only property or > subscript. The method decl is still something we can ascribe identity to.
That's true. My concern with ascribing identity to methods is that we have a number of features around methods — overloading, default arguments, various kinds of polymorphism — that make the exact choice of declaration somewhat imprecise. Should it be a different key path if we pick a protocol requirement vs. a concrete method that satisfies it? I suppose we have that specific problem with properties and subscripts as well, though. John. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution