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

Brent Royal-Gordon brent at architechies.com
Mon Apr 3 01:08:34 CDT 2017


> 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



More information about the swift-evolution mailing list