[swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Saagar Jha]

I’m along the lines of keeping the old behavior+warnings if “oldValue” is used for “newValue” and vice versa. Nonbreaking, and removes the issue of accidentally swapping the two.

Saagar Jha



> On Dec 3, 2016, at 7:33 PM, Derrick Ho via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I believe Erica's point about RIGHT NAMES ONLY is the most clear. While a block-like syntax using $0 is nice, it fails to communicate whether it is a newvalue or an oldvalue.
> 
> Therefore instead of following a block-like pattern it should follow a delegate-function like pattern. This would remove the ambiguity that $0 or name changing would present.
> 
> 
> set (newValue: TheType) {
> let a = newValue
> }
> 
> didSet (oldValue: TheType) {
> let b = oldValue
> }
> 

Hmm, why do we need “TheType”? Is this not conveyed by the actual property’s declaration?

> 
> 
> On Sat, Dec 3, 2016 at 10:06 PM Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> [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

Feels kind of “off”, since with closures the number represents a positional argument, but here the number has no value other than to match with closure syntax.

> 
> "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.)

+1 provided bug report is considered.

> 
> 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. 

-1, keeping “newValue” and “oldValue” is too restrictive, both in the case that there is another property with these names (causing potential confusion with self.newValue/self.oldValue), and in the case that the developer has a better description for the value.

> 
> 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.

See above, but this design is a bit less source breaking, at the expense of being less consistent.

> 
> 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 <wh1pch81n at gmail.com <mailto:wh1pch81n at gmail.com>> wrote:
>> 
>> I like this proposal!
>> 
>> +1
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20161203/2b1c54fb/attachment.html>