Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via email or direct message on the forums.
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Big +1. This is fills a small but important niche and will eliminate the need for libraries to include workarounds.
I especially appreciate this detail included in the proposal:
Appending an identity key path produces a key path equal to the other operand
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. If one wishes to support the whole value currently a separate overload is necessary.
Does this proposal fit well with the feel and direction of Swift?
Very much!
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I have not used any other languages with key paths exactly like those in Swift. Identity values are extremely common and useful in functional languages, including identity lenses which are roughly equivalent to the identity key path that is proposed here.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A quick read, although I have had to work around this limitation in the past and will be very happy to see it lifted.
It's a very good idea. I've wanted this feature once or twice when writing functions which usually use key paths but may sometimes make sense when applied to whole values; this proposal will fill that niche quite elegantly.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes; users cannot really correct this problem, and key paths are part of the ABI. This is the best time and means to solve the problem.
Does this proposal fit well with the feel and direction of Swift?
Yes. The \.self syntax is a direct, straightforward extension of existing features; it's exactly how you would expect this combination of features to work.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Smart identity key paths are much better than Cocoa KVC's self, which (for obvious reasons) can't actually replace the instance.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I've been following this proposal since it was pitched, although I haven't contributed heavily to the discussion.