By the way, does anybody know why the proposed syntax require a leading period 
for the key path?

#keyPath(Family, .pets.first)

In other words, why not just this:

#keyPath(Family, pets.first)


Or Brent's proposed:

#keyPath<Family>(pets.first)




> On Apr 3, 2017, at 2:08 AM, Brent Royal-Gordon via swift-evolution 
> <[email protected]> wrote:
> 
>> Proposal link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
> 
>>      • What is your evaluation of the proposal?
> 
> I continue to believe that the chosen syntax is unnecessarily cumbersome, 
> that the design is overly conservative in terms of making sure people never 
> "accidentally" use the feature, and that we could do a lot better.
> 
> But let's not throw the baby out with the bathwater. This is an *excellent* 
> proposal which addresses a real pain point for Swift users in a way that's 
> far better than not only the status quo, but any design Objective-C could 
> have offered. The only problem is that the syntax is ugly, and we can always 
> sugar it up later, once the community and core team are more comfortable with 
> the feature.
> 
> (However, I will make one last-ditch syntax suggestion: 
> `#keyPath<Family>(.pets.first)`, where the generic parameter list can be 
> omitted when it can be inferred from context. I think juxtaposing `<>` and 
> `()` is clearer than a comma followed by a dot.)
> 
>>      • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> How many "Swift isn't dynamic" blog posts have we all seen? This begins to 
> address their concerns.
> 
> How many code generation solutions have people come up with for lenses? This 
> lets us get rid of them *and* it's more efficient.
> 
> How many classes inherit from `NSObject` solely for introspection? This will 
> let some of those convert to native Swift classes.
> 
> Yes, it's a very significant problem.
> 
>>      • Does this proposal fit well with the feel and direction of Swift?
> 
> Yes; the lack of a property equivalent to unbound methods has always been a 
> gaping hole in the language, the clever type design is particularly Swifty. I 
> don't like the `#keyPath` part of the syntax, but the property/subscript 
> chain with optional chaining is super-Swifty as well. 
> 
>>      • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> In most respects, this is vastly superior to Objective-C KVC. I've never used 
> another language's lenses in anger, but I'm familiar with the theory of them, 
> and this proposal seems like a better solution than those too.
> 
>>      • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Does talking about it on the list a lot count?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to