[Original pitch: https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b <https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b>]
GENERAL FEEDBACK I received a gratifying amount of feedback about my pitch here, on Twitter, through email, on several Slack channels, and on IRC. I wanted to summarize the feedback, to start a new round of discussion. * A majority of respondents believe the current feature is incorrectly designed and that this is our best opportunity to change it. * A majority of respondents disagree on *how* it should be changed. Before I commit to the (non-trivial) effort of pushing on this, I'd like to know if any of the core team can chime in on the "preferred" design. Thank you. BUG REPORT The notion that the compiler should check for `set(oldValue)`, `willSet(oldValue)`, and `didSet(newValue)` and emit warnings or errors had pretty much universal support. I have submitted https://bugs.swift.org/browse/SR-3310 <https://bugs.swift.org/browse/SR-3310> to address this, regardless of whether the syntax changes or not. MENTIONING NAMES A majority of respondents prefer that argument names always be mentioned, whether or not they *can* be omitted. Consensus is that it's unSwifty to use pre-built `newValue` and `oldValue` arguments without mentioning them first. * The current system violates the principle of clarity. * It adds too much magic (https://en.wikipedia.org/wiki/Magic_(programming)) <https://en.wikipedia.org/wiki/Magic_(programming))> at the point of use. * It is inconsistent with the binding of variable names in closures. My original design, which I chose to provide the least impact on the compiler and existing code, was the least popular option. PREFERRED DESIGN The most popular design is that setters and property observers follow closures syntax, namely that the old value and new value arguments be passed as $0, and assignable using `name in`. Under this design, a setter looks like: ``` set { newValue in ... } // or set { somethingElse in ... } // or set { use $0 here } ``` Swift loses the "magic" newValue and oldValue, but any developer who normally prefers to mention the name before use has a simple, visible and easy way to retain that clarity. * Mirrors closure syntax * Easy to use * Loses magic names * Encourages documenting names in context "NO CHANGE" The second most popular design is "leave things as they are" (but implement the bug report.) Developers with good style habits will use mandatory `newValue` and `oldValue` names in their setter and observer declarations. No proposal is needed, and the bug report guards against potential errors. I would appreciate knowing whether the core team feels that the support for "no change", even from a smaller group of developers, disqualifies this issue from the high bar of Phase 1. (This group also included the most developers who self-reported that they did not use the override feature.) REMOVING OVERRIDES A third design entirely loses the ability to override variables or mention their names. This was in fact my *original* original design that I did not submit after sufficient devs told me they wanted to always spell out magic argument names. RIGHT NAMES ONLY Finally, the least popular design is my original pitch. (Only allow the "right" names, and allow them to be omitted.) This design has the least impact on the language, causes the least breaking for most use-cases, and allows most pro coders to continue using the "mention all names" approach. UPDATING PROPOSAL I am happy to update the proposal for the "closure-like" design. I believe there *was* reasonable consensus that the current system is out of step with Swift's design goals to push forward. However, I want this to go through another round of feedback. Thank you in advance for your comments. If this does move forward to a proposal, it must be discussed and decided in the first phase of Swift 4 as the change *is* breaking. -- Erica > On Dec 1, 2016, at 10:22 PM, Derrick Ho <[email protected]> wrote: > > I like this proposal! > > +1 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
