> On Mar 30, 2017, at 1:08 PM, Karl Wagner via swift-evolution 
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to