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

[David Hart]

I'm writing my review inline to this one:

> On 6 Apr 2017, at 02:27, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> 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
>> 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.

>> 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
> _______________________________________________
> 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/b4717db8/attachment.html>