<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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&lt;A,B&gt; is really (semantically) just a couple of functions, that is, (A) -&gt; B and (inout A,B) -&gt; (), so the (A) -&gt; 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&lt;A,B&gt; itself wherever a (A) -&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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&nbsp;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&nbsp;<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:&nbsp;<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:&nbsp;<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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>