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

[Tony Allevato]

On Wed, Apr 5, 2017 at 4:56 PM Douglas Gregor via swift-evolution <
swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170406/0f40e53e/attachment.html>