<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div></div><div>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.</div><div><br>On Jul 11, 2017, at 12:44 PM, BJ Homer <<a href="mailto:bjhomer@gmail.com">bjhomer@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">‘$' as a prefix is reserved for use by the debugger, so it cannot be used as a conversion operator here.<div class=""><br class=""></div><div class="">-BJ<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 11, 2017, at 10:12 AM, Robert Bennett 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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class="">On Jul 11, 2017, at 11:13 AM, Elviro Rocca via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" 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<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 class=""><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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></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></div></body></html>