[swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift
zach at waldowski.me
Mon Apr 3 10:20:07 CDT 2017
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
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.
zach at waldowski.me
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution