> On Apr 7, 2017, at 1:50 PM, Joe Groff via swift-evolution > <[email protected]> wrote: > > >> On Apr 7, 2017, at 11:48 AM, John McCall <[email protected]> wrote: >> >>> 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. > > 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.
I like where you guys are going with this! > > -Joe > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
