[Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift


(Douglas Gregor) #1

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
The core team’s feedback from the first review of this proposal can be viewed at:

https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

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?
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?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug

Review Manager


(Brent Royal-Gordon) #2

Proposal link:

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


(Matthew Johnson) #3

What is your evaluation of the proposal?

This proposal is excellent. A big thanks goes out to everyone who worked on it!

The \ sigil may not make for the prettiest syntax but our options are very limited and it is a vast improvement over the previous draft. If the core team likes the :: suggestion others have made I would be also be fine with that if we could elide the leading `.` in the shorthand version but would prefer not to have to write `::.`. Overall, the choice of sigil is relatively unimportant to me. The important thing IMO is that it is concise and will work great in DSLs.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes. The lack of unbound property references is a big hole in the language.

Does this proposal fit well with the feel and direction of Swift?

Absolutely.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have used lenses a bit in my own code. Key paths are a really awesome way to build them right into the language with syntactic support that is not possible for libraries.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

In depth study.


(Charles Srstka) #4

+1. This looks fantastic.

Charles

···

On Apr 5, 2017, at 6:56 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
The core team’s feedback from the first review of this proposal can be viewed at:

https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

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?
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?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tony Allevato) #5

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for
Swift" begins now and runs through April 9, 2017. The revised proposal is
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md

The core team’s feedback from the first review of this proposal can be
viewed at:

https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:

Proposal link:

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?

Full on +1 now. Thank you for reverting the heavy syntax from the previous

revision. This makes the feature much more usable, and the future alignment
with unbound function references will be welcome in terms of consistency.

I guess I'll throw out my own color for the shed: Was :: already
considered as well? It at least has some precedent in C++ and later Java
for similar purposes, and it's not currently an operator in the language.
We could have:

    Person.foo // a reference to Person's static property foo
    Person::foo // a keypath to Person's instance property foo

Then, for SE-0042:

    Person::someFunction // a function reference of type (Person, ...other
args...) -> Result

But that might make the implied case look strange. Would we have to have
this?

    print(luke[keyPath: ::.friends[0].name])

Without the period after the "::", it's inconsistent with other type
inference sites, but with it, it's kind of ugly.

That being said, if the backslash ends up being the operator of record for
this feature because other options would be poor choices for other reasons,
I'm ok with that.

My feedback on the rest of the proposal review bullets is the same as
before; I won't repeat it here.

···

On Wed, Apr 5, 2017 at 4:56 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

   - 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?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug

Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(James Berry) #6

+1 to this revised proposal.

I think the backslash is good. Even if it looks a little funny on first blush, I think it’s the best choice. I don’t like other’s suggestion of ‘keypath’, which I think is confusingly string-like: single quotes should be saved for possible string expansions.

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md

What is your evaluation of the proposal?

Strong +1. Let’s get this done.

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?

Yes

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

This is great.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

In-depth.

···

On Apr 5, 2017, at 4:56 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:


(Martin Waitz) #7

Hello,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.mdI really like this version of the proposal with the backslash.

Have you also considered using the backslash when using the KeyPath?

E.g. `person\.bestFriendsName` instead of `person[keyPath: bestFriendsName]`

— Martin


(Brad Hilton) #8

-1. Not a huge fan of the back slash. Doesn’t make sense considering we can refer to unapplied method references without the backslash. Maybe we can settle on some unified syntax for both? How about Person.name.get / Person.name.set for getter/setter references.

···

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
The core team’s feedback from the first review of this proposal can be viewed at:

https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

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?
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?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug

Review Manager


(Rick M) #9

I tend to dislike the backslash as well, but can't suggest a good alternative.

Does any of this allow for operations within the key path? e.g. Department.employees.@sum.salary?

Also, in this example:

let firstFriendsNameKeyPath = \Person.friends[0].name
let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"

Can't we do without the keyPath: argument name? The compiler knows it's a keypath, it would be nicer to write

let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"

···

On Apr 5, 2017, at 16:56 , Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
The core team’s feedback from the first review of this proposal can be viewed at:

https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
Reply text
Other replies
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?
  • 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?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Rick Mann
rmann@latencyzero.com


(John McCall) #10

Something came to mind that I wanted to record, even though it's not directly addressed by this proposal.

I know that one future direction here is that key paths ought to be equatable, serializable, etc. Serialization in particular is something that we're going to have to think about very carefully.

In general, it's really bad for deserialization to be able to call arbitrary code in the program. There is a well-known security hole in various reflective deserialization libraries where they will happily call arbitrary functions or constructors if they're named in the serialized data. (Often, there's some way to limit this, but you have to know to use it — so it's merely the default that isn't secure, but that's no defense.) A Swift serialization library would hopefully be designed around a protocol that provided a (throwing) deserializing initializer, so that (1) types have to opt in to supporting deserialization and (2) deserialization doesn't call completely arbitrary code. But it's still a potential security hole if deserialization can construct a key path that, when accessed, will execute arbitrary code in the process.

There are other concerns as well. It's a code-size and performance problem if we have to treat every property and subscript in the program as potentially used, and emit key-path metadata for them, just in case they might be used by a deserialized key path. And, of course, it potentially becomes a binary compatibility problem to remove a property or subscript, even a private one, if that was ever used in a key path that was serialized. But the biggest concern is security.

Anyway, just a thought that shouldn't be allowed to derail this proposal.

John.

···

On Apr 5, 2017, at 7:56 PM, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md


(Thorsten Seitz) #11

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
What is your evaluation of the proposal?

+1 in general

BUT I absolutely dislike having to escape a key path with `\` which is absolutely counterintuitive IMHO.
Like Brent already wrote, the `\` has to encompass the full expression to avoid ambiguities; this is so foreign to how `\` usually works, i.e. only on the following character, that it further makes the syntax counterintuitive and ugly.

I would have preferred one of these

1.
@{Type.property[.property]*}
  // no ambiguities due to braces
  let kp = @{Person.bestFriend?.name}
  luke[keyPath: @{.bestFriend?.name}]

2.
@Type.property[.property]*
  // @ applies to whole expression to make unambiguous (just like Brent suggested for `\`)
  let kp = @Person.bestFriend?.name
  luke[keyPath: @.bestFriend?.name]

3.
Type@property[.property]*
  // @ applies to whole expression to make unambiguous (just like Brent suggested for `\`)
  let kp = Person@bestFriend?.name
  luke[keyPath: @bestFriend?.name]

4.
Type@property[@property]*
  // no ambiguities due to different separators; might be used for method references as well
  let kp = Person@bestFriend?@name
  luke[keyPath: @bestFriend?@name]

5.
#keyPath(Type.property[.property]*)
  // no ambiguities due to parenthesis
  let kp = #keyPath(Person.bestFriend?.name)
  luke[keyPath: #keyPath(.bestFriend?.name)]

Is the problem being addressed significant enough to warrant a change to Swift?

Yes, definitely!

Does this proposal fit well with the feel and direction of Swift?

Yes.

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?

Followed much of the discussion, read the proposal.

-Thorsten


(Tino) #12

-1:
Although prefix "\" is imho the nicest variation that has been officially suggested for this feature (I still like infix ":" better; maybe I've been using classic MacOS to long), there is no general agreement, and many people that voted "+1" did so despite preferring a different syntax, just because they want to have the feature asap.

But haste is a bad counsellor, and if we learned anything from the disaster of "new private", we shouldn't rush and constitute how an obviously important (or at least popular) feature should look like without taking into account the big picture:
KeyPaths are at least entwined with method references and reflection, so until we have a concrete idea of those ties, no narrow proposal should be implemented*.

- Tino

* preliminary acceptance with delayed implementation would be fine for me — I just don't want to paint ourselves into a corner...


(David Beck) #13

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
The core team’s feedback from the first review of this proposal can be viewed at:

https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

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’m a very big fan of solving this problem, and this seems like a pretty flexible solution for the future.

I like the “::” solution, but could live with the proposed syntax. Also, that seems like an aspect that could be changed, either additively, or at the very least without breaking ABI stability.

Is the problem being addressed significant enough to warrant a change to Swift?

YES! While KVO and KVC are big use cases for key paths, other use cases exist that make sense for non-objc code to use, especially db related models.

Does this proposal fit well with the feel and direction of Swift?

For the most part. Like many have said, the slash is a little out of place, but hen again, that’s why it was chosen, so that it doesn’t conflict with other operators.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Most languages that I’ve used this kind of feature with (including ObjC) just use stringly typed constructs, which have obvious issues.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

a quick reading

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug

Review Manager

David Beck
davidb@acst.com
http://www.acstechnologies.com


(Brent Royal-Gordon) #14

I realized after sending that this may have sounded more negative than I meant it to be. The backslash is not perfect, but it is more than acceptable, and I'm sure I'll get used to it. I recommend the proposal be accepted.

···

On Apr 5, 2017, at 6:41 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

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.

--
Brent Royal-Gordon
Architechies


(Harlan Haskins) #15

+1 for using ::

It’s got precedence in many other languages (C++, Java 8+, Kotlin) to reference static methods, and it’s sufficiently different enough from `.` to avoid confusing people.

While I personally resist letting C++ influence Swift syntactically, this makes a lot of sense to me.

— Harlan

···

On Apr 5, 2017, at 8:27 PM, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Apr 5, 2017 at 4:56 PM Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
The core team’s feedback from the first review of this proposal can be viewed at:

https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

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?
Full on +1 now. Thank you for reverting the heavy syntax from the previous revision. This makes the feature much more usable, and the future alignment with unbound function references will be welcome in terms of consistency.

I guess I'll throw out my own color for the shed: Was :: already considered as well? It at least has some precedent in C++ and later Java for similar purposes, and it's not currently an operator in the language. We could have:

    Person.foo // a reference to Person's static property foo
    Person::foo // a keypath to Person's instance property foo

Then, for SE-0042:

    Person::someFunction // a function reference of type (Person, ...other args...) -> Result

But that might make the implied case look strange. Would we have to have this?

    print(luke[keyPath: ::.friends[0].name])

Without the period after the "::", it's inconsistent with other type inference sites, but with it, it's kind of ugly.

That being said, if the backslash ends up being the operator of record for this feature because other options would be poor choices for other reasons, I'm ok with that.

My feedback on the rest of the proposal review bullets is the same as before; I won't repeat it here.

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?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ricardo Parada) #16

Good point.

I'm thinking about the hypothetical code examples from previous emails:

   let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
   let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
   let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)

···

On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

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.


(David Hart) #17

I'm writing my review inline to this one:

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
The core team’s feedback from the first review of this proposal can be viewed at:

https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
Reply text
Other replies
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?

Full on +1 now. Thank you for reverting the heavy syntax from the previous revision. This makes the feature much more usable, and the future alignment with unbound function references will be welcome in terms of consistency.

I'm also +1 on this new revision.

I guess I'll throw out my own color for the shed: Was :: already considered as well? It at least has some precedent in C++ and later Java for similar purposes, and it's not currently an operator in the language. We could have:

I proposed it during discussion. He only counter that I heard was that it was potentially reserved for name-spacing.

    Person.foo // a reference to Person's static property foo
    Person::foo // a keypath to Person's instance property foo

Then, for SE-0042:

    Person::someFunction // a function reference of type (Person, ...other args...) -> Result

But that might make the implied case look strange. Would we have to have this?

    print(luke[keyPath: ::.friends[0].name])
Without the period after the "::", it's inconsistent with other type inference sites, but with it, it's kind of ugly.

That being said, if the backslash ends up being the operator of record for this feature because other options would be poor choices for other reasons, I'm ok with that.

Same, I have a small preference for :: but I'd be ok with backslash.

My feedback on the rest of the proposal review bullets is the same as before; I won't repeat it here.

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?

Yep!

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Nope.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

In depth study.

···

On 6 Apr 2017, at 02:27, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Apr 5, 2017 at 4:56 PM Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Douglas Gregor) #18

-1. Not a huge fan of the back slash. Doesn’t make sense considering we can refer to unapplied method references without the backslash. Maybe we can settle on some unified syntax for both? How about Person.name.get / Person.name.set for getter/setter references.

Did you read the core team’s commentary on unapplied method references?

  https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html <https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html<https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html>>

?
  - Doug

···

On Apr 6, 2017, at 11:01 AM, Brad Hilton <brad.hilton.nw@gmail.com> wrote:

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
The core team’s feedback from the first review of this proposal can be viewed at:

https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

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?
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?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug

Review Manager


(Ricardo Parada) #19

The escape character is already being used in String interpolation, i.e. \(foo). Also, escaping special characters in string literals, i.e. \t is tab, \n is a newline character, etc. The single quote does not appear to be in use. I believe it's not being used for string literals nor character literals:

ERROR at line 6, col 21: single-quoted string literal found, use '"'
let someCharacter = 'a'
                    ^~~
                    "a"

Based on this, I don't think the use of single quote is a bad idea for Swift's smart key paths, IMHO.

But if the core team decides is reserved for something else, the escape character would be fine with me. But I do think the single quote would be slightly superior to the escape character.

···

On Apr 6, 2017, at 11:35 AM, James Berry via swift-evolution <swift-evolution@swift.org> wrote:

+1 to this revised proposal.

I think the backslash is good. Even if it looks a little funny on first blush, I think it’s the best choice. I don’t like other’s suggestion of ‘keypath’, which I think is confusingly string-like: single quotes should be saved for possible string expansions.

On Apr 5, 2017, at 4:56 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md

What is your evaluation of the proposal?

Strong +1. Let’s get this done.

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?

Yes

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

This is great.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

In-depth.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brad Hilton) #20

Yes. I'd prefer to keep unapplied method references the same and do
properties the same way IMHO.

···

On Thu, Apr 6, 2017 at 12:05 PM, Douglas Gregor <dgregor@apple.com> wrote:

On Apr 6, 2017, at 11:01 AM, Brad Hilton <brad.hilton.nw@gmail.com> wrote:

-1. Not a huge fan of the back slash. Doesn’t make sense considering we
can refer to unapplied method references without the backslash. Maybe we
can settle on some unified syntax for both? How about Person.name.get /
Person.name.set for getter/setter references.

Did you read the core team’s commentary on unapplied method references?

https://lists.swift.org/pipermail/swift-evolution-
announce/2017-April/000342.html<https://lists.swift.org/
pipermail/swift-evolution-announce/2017-April/000342.html>

?
- Doug

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for
Swift" begins now and runs through April 9, 2017. The revised proposal is
available here:

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>
The core team’s feedback from the first review of this proposal can be
viewed at:

https://lists.swift.org/pipermail/swift-evolution-
announce/2017-April/000342.html<https://lists.swift.org/
pipermail/swift-evolution-announce/2017-April/000342.html>
Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution<
https://lists.swift.org/mailman/listinfo/swift-evolution>
or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:

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?
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?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md<
https://github.com/apple/swift-evolution/blob/master/process.md>
Thank you,

-Doug

Review Manager