[swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Joe Groff]

> On Mar 30, 2017, at 1:08 PM, Karl Wagner via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 	• What is your evaluation of the proposal?
> +1
> 
>> 	• Is the problem being addressed significant enough to warrant a change to Swift?
> Yes
> 
>> 	• Does this proposal fit well with the feel and direction of Swift?
> Yes
> 
>> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> Lots of languages have key-paths, but usually they are strings. This adds some type-safety, so that’s nice.
> 
>> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> A quick reading. I also have a couple of questions:
> 
> 1) Can we get keypaths from protocol existentials?
> 
> protocol MyProto {
>     var something: Int { get }
> }
> struct MyThing: MyProto { /* … */ }
> 
> let myProtoSomethingKeypath = #keypath(MyProto, .something)
> let value: Int = MyThing()[keypath: myProtoSomethingKeypath]  // seems reasonable, right?

Yeah, that would be a natural thing to support.

> 2) What about if it has associated types?
> 
> let secondElement = #keypath(Collection, .subscript[1])  // if Collection.Iterator.Element had constraints, could we dig in to the instance?
> 
> let _: Int = [1,2,3][keypath: secondElement]
> let _: String = [“a”, “b”, “c”][keypath: secondElement]
> 
> 
> But I’d still +1 the proposal even if was limited to concrete types.
> 
> Also, that brings me to 2 related comments regarding the evolution of the feature:
> 
> 1) It would be nice to allow keypaths of constrained protocol existentials
> 
>     let secondElementFirstCharacter = #keypath(Collection where Iterator.Element == String, .subscript[0].characters.first)

These would rely on supporting generalized existentials in the language at large.

> 2) It would be nice to be able to get keypaths to members which we don’t know exist. Members and protocol conformances may be retroactively added by 3rd-party code.

You could define a library function that applies a key path to a base value, if the base value is castable to the root type of the key path. That might be a useful enough thing to absorb into the standard library at some point, but it doesn't seem to me like it strictly needs to be part of the core proposal.

-Joe