<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>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.</div><div><br></div><div>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] }</div><div><br>On Jul 11, 2017, at 11:13 AM, Elviro Rocca via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Elviro</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Il giorno 05 lug 2017, alle ore 19:08, Benjamin Herzog via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> ha scritto:</div><br class="Apple-interchange-newline"><div class="">
<title class=""></title>
<div class=""><div class="">Hey guys,<br class=""></div>
<div class=""><br class=""></div>
<div class="">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.<br class=""></div>
<div class="">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.<br class=""></div>
<div class="">I propose using <br class=""></div>
<div class=""><br class=""></div>
<div class="">persons.flatMap(keyPath: \.name)<br class=""></div>
<div class=""><br class=""></div>
<div class="">over<br class=""></div>
<div class=""><br class=""></div>
<div class="">persons.flatMap { $0.name }<br class=""></div>
<div class=""><br class=""></div>
<div class="">Link to pull request: <a href="https://github.com/apple/swift/pull/10760" class="">https://github.com/apple/swift/pull/10760</a><br class=""></div>
<div class=""><br class=""></div>
<div class="">Link to proposal draft: <a href="https://github.com/BenchR267/swift-evolution/blob/keypath-based-map/proposals/0181-keypath-based-map-flatmap-filter.md" class="">https://github.com/BenchR267/swift-evolution/blob/keypath-based-map/proposals/0181-keypath-based-map-flatmap-filter.md</a><br class=""></div>
<div class=""><br class=""></div>
<div class="">Thanks in advance for your feedback!<br class=""></div>
<div id="sig64302232" class=""><div class="signature">______________________<br class=""></div>
<div class="signature"><br class=""></div>
<div class="signature">Benjamin Herzog<br class=""></div>
</div>
<div class=""><br class=""></div>
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>