<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 8. Jun 2017, at 04:58, Tony Allevato 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="">+1, I really like this. It would also align nicely with the method type flattening in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md" class="">SE-0042</a> (once it gets implemented), because passing keypaths (i.e., unbound property references) and unbound parameterless method references to map/flatMap would look nearly the same:<br class=""><div class=""><br class=""></div><div class="">```</div><div class="">struct Person {</div><div class=""> let firstName: String</div><div class=""> let lastName: String</div><div class=""> func fullName() -> String { return "\(firstName) \(lastName)" }</div><div class="">}</div><div class=""><br class=""></div><div class="">let people: [Person]</div><div class="">let firstNames = people.map(\.firstName)</div><div class="">let fullNames = people.map(Person.fullName) // because after SE-0042, this will be (Person) -> String, not (Person) -> () -> String</div><div class="">```</div><div class=""><br class=""></div><div class="">Especially if there's a move in the future to also use \. to denote unbound methods references, which was discussed during the keypath reviews. (Even with that, I believe it would be more work though to get rid of the explicit type name in the function case.)</div><div class=""><br class=""></div></div><br class=""></div></blockquote><div><br class=""></div><div>When it comes to unbound method references, personally, I would love to see us ditch currying in some future version of Swift and move to full-blown partial application instead. We would need variadic generics if we wanted to expose them as nicely-typed objects as we do with KeyPaths.</div><div><br class=""></div><div>Anyway, I think what you want is something like this (where VirtualKeyPath is a custom subclass of KeyPath which is lazily-evaluated using a closure).</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><font face="Menlo" class="">extension KeyPath where Value: Collection {</font></div></div><div><div><font face="Menlo" class=""> func map<T>(_ descendent: KeyPath<Value, T>) -> VirtualKeyPath<Root, [T]> {</font></div></div><div><div><font face="Menlo" class=""> return VirtualKeyPath<Root, [T]> { </font></div></div><div><div><font face="Menlo" class=""> (obj: Root) -> [T] in obj[keypath: self].map { $0[keypath: descendent] } </font></div></div><div><div><font face="Menlo" class=""> }</font></div></div><div><div><font face="Menlo" class=""> }</font></div></div><div><div><font face="Menlo" class="">}</font></div></div><div><div><font face="Menlo" class=""><br class=""></font></div></div><div><div><font face="Menlo" class="">\Department.people.map(\.fullName).characters.count // type: VirtualKeyPath<Department, [Int]></font></div></div></blockquote><div><div><br class=""></div><div><br class=""></div><div>Custom subclasses of KeyPath are not allowed, so you can’t actually do this. I don’t know, maybe it wouldn’t be much overhead to add the one, closure-based VirtualKeyPath — clearly the architecture is meant to be flexible. Maybe it’s better to wait until Swift 5 for that, though.</div><div><br class=""></div><div>- Karl</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jun 7, 2017 at 6:11 PM Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1. Would think that all variants should exist on Optional too unless it would be harmful.<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jun 7, 2017 at 20:13 Michael J LeHew Jr via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a great idea, and ought to be easy enough to bring forward! +1 from me!<br class="">
<br class="">
-Michael<br class="">
<br class="">
> On Jun 7, 2017, at 11:18 AM, Matt Diephouse via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> 💯<br class="">
><br class="">
>> On Jun 7, 2017, at 10:35 AM, Adam Sharp via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>><br class="">
>> The new smart key path feature is really lovely, and feels like a great addition to Swift.<br class="">
>><br class="">
>> It seems like it might be straightforward to add overloads of `map` and `flatMap` to the standard library to make use of the new functionality:<br class="">
>><br class="">
>> let managers = flatOrganisation.managers<br class="">
>> let allEmployees = Set(managers.flatMap(\.directReports))<br class="">
>> let employeeNames = Set(allEmployees.map(\.name))<br class="">
>><br class="">
>> This feels like a really natural way of working with key paths in a functional style. It makes a lot of sense for collections, and possibly for Optional too (although as far as I can see optional chaining is more or less equivalent, and with more compact syntax).<br class="">
>><br class="">
>> I’m hoping that this might be low-hanging fruit that could be considered for the Swift 4 release. I’d be happy to have a go at writing a proposal if there’s interest!<br class="">
>><br class="">
>> –Adam<br class="">
>><br class="">
>> _______________________________________________<br class="">
>> swift-evolution mailing list<br class="">
>> <a href="mailto:swift-evolution@swift.org" target="_blank" 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/mailman/listinfo/swift-evolution</a><br class="">
><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" target="_blank" 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/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" 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/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" 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/mailman/listinfo/swift-evolution</a><br class="">
</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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>