<div dir="ltr">How would you feel about wrapping the existing functions on _KVOKeyPathBridgeMachinery:<div><br><div>@nonobjc fileprivate static func _bridgeKeyPath(_ keyPath:AnyKeyPath) -> String</div><div>@nonobjc fileprivate static func _bridgeKeyPath(_ keyPath:String?) -> AnyKeyPath?</div><div><br></div><div>In extensions on String and AnyKeyPath respectively to instantiate strings from KeyPaths and KeyPaths from Strings?</div><div><br></div><div><a href="https://github.com/apple/swift/blob/c5ff1f2cac8da6a14330f4b033b94c7c926d2126/stdlib/public/SDK/Foundation/NSObject.swift#L84">https://github.com/apple/swift/blob/c5ff1f2cac8da6a14330f4b033b94c7c926d2126/stdlib/public/SDK/Foundation/NSObject.swift#L84</a><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 25, 2017 at 11:43 AM Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Aug 23, 2017, at 11:18 PM, Logan Shire via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Hey folks!<br>
><br>
> Recently I’ve been working on a small library which leverages the Swift 4 Codable protocol<br>
> and KeyPaths to provide a Swift-y interface to CoreData. (It maps back and forth between<br>
> native, immutable Swift structs and NSManagedObjects). In doing so I found a couple of<br>
> frustrating limitations to the KeyPath API. Firstly, KeyPath does not provide the name of the<br>
> property on the type it indexes. For example, if I have a struct:<br>
><br>
><br>
> struct Person {<br>
> let firstName: String<br>
> let lastName: String<br>
> }<br>
><br>
> let keyPath = \Person.firstName<br>
><br>
><br>
> But once I have a keyPath, I can’t actually figure out what property it accesses.<br>
> So, I wind up having to make a wrapper:<br>
><br>
><br>
> struct Attribute {<br>
> let keyPath: AnyKeyPath<br>
> let propertyName: String<br>
> }<br>
><br>
> let firstNameAttribute = Attribute(keyPath: \Person.firstName, propertyName: “firstName”)<br>
><br>
><br>
> This forces me to write out the property name myself as a string which is very error prone.<br>
> All I want is to be able to access:<br>
><br>
><br>
> keyPath.propertyName // “firstName”<br>
><br>
><br>
> It would also be nice if we provided the full path as a string as well:<br>
><br>
><br>
> keyPath.fullPath // “Person.firstName"<br>
><br>
><br>
> Also, if I want to get all of the attributes from a given Swift type, my options are to try to hack<br>
> something together with Mirrors, or forcing the type to declare a function / computed property<br>
> returning an array of all of its key path / property name pairings. I would really like to be able to<br>
> retrieve a type-erased array of any type’s key paths with:<br>
><br>
><br>
> let person = Person(firstName: “John”, lastName: “Doe”)<br>
> let keyPaths = Person.keyPaths<br>
> let firstNameKeyPath = keyPaths.first { $0.propertyName = “firstName” } as! KeyPath<Person, String><br>
> let firstName = person[keypath: firstNameKeyPath] // “John"<br>
><br>
><br>
> And finally, without straying too far into Objective-C land, it would be nice if we could initialize key paths<br>
> with a throwing initializer.<br>
><br>
><br>
> let keyPath = try Person.keyPath(“firstName”) // KeyPath<Person, String> type erased to AnyKeyPath<br>
> let keyPath = AnyKeyPath(“Person.firstName”)<br>
><br>
><br>
> Let me know what you think about any / all of these suggestions!<br>
<br>
These would all be great additional features to eventually add to key paths. I think reflection mechanisms centered on key paths like what you describe would be a superior replacement for most of what Mirror attempts to provide.<br>
<br>
-Joe</blockquote></div></div></div></div>