SE-0227: Identity Key Path

The review of SE-0223: Identity key path begins now and runs through Friday, September 14th, 2018.

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?

Thank you for contributing to Swift!

Ben Cohen
Review Manager

9 Likes
  • What is your evaluation of the proposal?

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.

  • What is your evaluation of the proposal?

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.

  • +1
  • Yes
  • Yes
  • Fits well with Objective-C in spelling; usefulness of identity fn is well justified in FP literature
  • Read it once through
1 Like

+1

Yes

Yes, especially key paths

Aligns well with uses of identity with lenses, but also has many other valuable uses.

Briefly followed the initial discussion and read this proposal.

+1. Same for me too

+1 echoing the same comments as others!

Hi everyone – the review period has ended and the proposal is accepted.

2 Likes