<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="">Thanks for the feedback! I also like the idea where this is pivoting and would like to think deeper about the topic and possible solutions. I will change the proposal and polish it. <div class="">I would still like to use this thread to get more input if there is more.</div><div class=""><br class=""></div><div class=""><div class="signature">______________________<br class=""></div><div class="signature"><br class=""></div><div class="signature">Benjamin Herzog</div><div class="signature"><br class=""></div><div><blockquote type="cite" class=""><div class="">On 6. Jul 2017, at 01:15, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">My initial reaction when this idea was floated was positive, but after Dave and others' astute observations, I have come to the same opinion as him. Namely, it seems hard to justify adding an overload that's purely syntactic sugar, multiplying the number of ways to express the same thing, for a result where the increase in readability is debatable.<div class=""><br class=""></div><div class="">Agree also that _if_ this is worthwhile, then keypaths as a subtype of the corresponding function type would be the best way to go.<div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jul 5, 2017 at 4:23 PM, Dave Abrahams via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
on Wed Jul 05 2017, Benjamin Herzog <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
<br class="">
> Hey guys,<br class="">
><br class="">
> I would like to pitch a small convenient change to the Swift stdlib.<br class="">
> With KeyPaths added in SE-0161 I would like to add some convenience<br class="">
> calls to map, flatMap and filter in Sequences. To extract properties of<br class="">
> an array of objects we currently use trailing closure syntax together<br class="">
> with the shorthand $0 for the first closure argument. This is still kind<br class="">
</span>> of verbose and also hard to read in some situations.I think it is much better to understand what is<br class="">
<span class="">> going on when using the<br class="">
> type safe KeyPaths for that. I already implemented a working solution<br class="">
> and would like to pitch the idea here to get some feedback before<br class="">
</span>> opening the swift evolution proposal.I propose using<br class="">
<span class="">><br class="">
> persons.flatMap(keyPath: \.name)<br class="">
><br class="">
> over<br class="">
><br class="">
> persons.flatMap { $<a href="http://0.name/" rel="noreferrer" target="_blank" class="">0.name</a> }<br class="">
><br class="">
> Link to pull request: <a href="https://github.com/apple/swift/pull/10760" rel="noreferrer" target="_blank" class="">https://github.com/apple/<wbr class="">swift/pull/10760</a><br class="">
<br class="">
</span>Repeating my earlier response to this idea:<br class="">
<br class="">
I am not convinced this syntactic sugar is worth complicating the<br class="">
language or library for, but if it is, IMO the right thing is to make a<br class="">
keypath be-a subtype of the appropriate function type, rather than to<br class="">
start down the path of creating a keypath overload for every method that<br class="">
takes a closure argument.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
--<br class="">
-Dave<br class="">
<br class="">
______________________________<wbr class="">_________________<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" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
</font></span></blockquote></div><br class=""></div></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></body></html>