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 [email protected]
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
