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