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

[Zach Waldowski]

On Thu, Mar 30, 2017, at 12:25 PM, Douglas Gregor wrote:
>  * What is your evaluation of the proposal?


Weak +0.5. This is absolutely needed, and I don't want to see the
feature broken down any further through interminable bikeshedding,
so I'd be more willing to let it ride as-is than miss out on having
this feature.


I was personally quite happy with the original proposal text. Worrying
about interaction with type properties reminds me of the pearl-clutching
when lightweight generics were added to ObjC over ambiguity with
protocol conformance statements, to which, IIRC, the involved people
stated, "Don't worry. The compiler's got this. It's its job."


I can't really get behind a syntax with this amount of clunkiness. The
second example — `foo[keyPath: #keyPath(.bar.baz)]` — is egregious.
Perhaps the proposal is right that you'd rarely see it, but I take
umbrage with "never". Teaching smart key paths will require building up
from base principles just like the proposal, and from that perspective
it looks like a syntax designed out of compatibility concerns in a much
older language, not the best it could be on its own.


The leading dot inference is extremely desirable to limit repetition,
but the difference in behavior with lookup for #selector and ObjC-style
#keyPath will be confusing for many. "Why was it not compiling?" "You
have a leading dot when you shouldn't." That doesn't sound like a
satisfying experience unless the diagnostic is truly superlative.


Ultimately, the Core Team and the community have to make an opinionated
decision about this feature's impact on the language. Though I
understand (and believe in) progressive disclosure, I don't think it
behooves us to "hide" "advanced" syntax. `#foo` sigils feel like compatibility-
driven hacks. If, like me, you think unbounded methods and unbounded
properties form the lowercase-f foundation for Swift's answer to Cocoa-
quality dynamism, then the feature should have that policy reflected
appropriately in its syntax.

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


Absolutely. See what I say above — the time is right for well-
considered, powerful, but low-impact language additions. Key-paths would
be a sea-change for data-flow (reactive, etc.) frameworks and for DSLs.

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


The feature — yes. The syntax — not quite.


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


I've extensively used Cocoa's similar features. I can see, perhaps
just barely, where AnyKeyPath would be NSKeyPath in another universe,
and in that sense it's a great accomplishment building out these
features for Swift.

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


In-depth study of the original proposal; followed the mailing list
threads; quick re-review of the modified proposal.


Sincerely,

  Zachary Waldowski

  zach at waldowski.me




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170403/7d17c7d0/attachment.html>