This is also the case for $0, although I suppose that since $0 is only valid inside a closure, LLDB has some context with which to disambiguate Swift’s $0 from LLDB’s, context it wouldn’t have with $keyPath. That said, there are probably solutions to this, like requiring a backslash before a Swift dollar sign to disambiguate from an LLDB dollar sign. Or something else. Designing the language with constraints imposed by the debugger seems unduly restrictive, though – surely the debugger should be subservient to the language, not the other way around.
> On Jul 11, 2017, at 12:44 PM, BJ Homer <[email protected]> wrote: > > ‘$' as a prefix is reserved for use by the debugger, so it cannot be used as > a conversion operator here. > > -BJ > >> On Jul 11, 2017, at 10:12 AM, Robert Bennett via swift-evolution >> <[email protected]> wrote: >> >> It seems that there is some consensus that the proper way to achieve this is >> not to overload map et al. but to provide a way to convert KeyPath to a >> function. I agree – not only is this “cheaper”, as overloads of these >> functions will not need to be written, but it’s also more general and may >> prove useful in a context that we currently don’t foresee. >> >> This being the case, I’ll repeat my proposal that the optimal way to achieve >> this is to make $ the conversion “operator” (although it need not, and >> probably should not, be a full-fledged operator), so that $keyPath –> { >> $0[keyPath: keyPath] } >> >>> On Jul 11, 2017, at 11:13 AM, Elviro Rocca via swift-evolution >>> <[email protected]> wrote: >>> >>> Overloads are ugly. The very existence of an overloaded function usually >>> means a lack of available abstractions, or an insufficient abstraction >>> power in the language: exhibit A is conditional conformances to protocols. >>> >>> Overloads are particularly ugly if the overloaded function's input >>> represents basically the same thing: a KeyPath<A,B> is really >>> (semantically) just a couple of functions, that is, (A) -> B and (inout >>> A,B) -> (), so the (A) -> B is already there, and I like the idea of an >>> "extraction" operator that was proposed in the thread. It would be really >>> interesting to just use the KeyPath<A,B> itself wherever a (A) -> B is >>> required, but this looks like a hack given the current state of Swift's >>> type system. >>> >>> But I like the fundamental idea behind the proposal: KeyPaths give Swift a >>> boost in expressive power, and there's probably plenty of use cases that >>> will emerge in the future. >>> >>> Thanks >>> >>> >>> Elviro >>> >>>> Il giorno 05 lug 2017, alle ore 19:08, Benjamin Herzog via swift-evolution >>>> <[email protected]> ha scritto: >>>> >>>> Hey guys, >>>> >>>> I would like to pitch a small convenient change to the Swift stdlib. With >>>> KeyPaths added in SE-0161 I would like to add some convenience calls to >>>> map, flatMap and filter in Sequences. To extract properties of an array of >>>> objects we currently use trailing closure syntax together with the >>>> shorthand $0 for the first closure argument. This is still kind of verbose >>>> and also hard to read in some situations. >>>> I think it is much better to understand what is going on when using the >>>> type safe KeyPaths for that. I already implemented a working solution and >>>> would like to pitch the idea here to get some feedback before opening the >>>> swift evolution proposal. >>>> I propose using >>>> >>>> persons.flatMap(keyPath: \.name) >>>> >>>> over >>>> >>>> persons.flatMap { $0.name } >>>> >>>> Link to pull request: https://github.com/apple/swift/pull/10760 >>>> >>>> Link to proposal draft: >>>> https://github.com/BenchR267/swift-evolution/blob/keypath-based-map/proposals/0181-keypath-based-map-flatmap-filter.md >>>> >>>> Thanks in advance for your feedback! >>>> ______________________ >>>> >>>> Benjamin Herzog >>>> >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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
