> Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md> > Reply text > Other replies > > <https://github.com/apple/swift-evolution/pulls#what-goes-into-a-review-1>What > goes into a review? > > The goal of the review process is to improve the proposal under review > through constructive criticism and, eventually, determine the direction of > Swift. When writing your review, here are some questions you might want to > answer in your review: > > What is your evaluation of the proposal? I don't adore the `\` syntax because I don't quite see the underlying logic of that symbol, but it's a *massive* improvement over the old `#keyPath(Type, .path)` mess, and in all other respects I remain extremely positive on this proposal.
It's worth noting that, if you write `\Person.name.valueType`, this syntax is ambiguous—it could mean "make a key path for the `valueType` property on `name` property of `Person`", or it could mean "make a key path for the `name` property of `Person`, then access the key path's `valueType` property". We can solve this by always interpreting it as the former and requiring parentheses for the latter—that is, `(\Person.name).valueType`—but I thought it was worth calling out explicitly. > 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? Pretty much. > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? Just Objective-C. This is much better. > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? Quick reading of this revision. -- Brent Royal-Gordon Architechies
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
