‘$' 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] <mailto:[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] <mailto:[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 >>> <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 >>> >>> <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] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
