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

[Erica Sadun]

[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 <wh1pch81n at gmail.com> wrote:
> 
> I like this proposal!
> 
> +1
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161203/89e289fb/attachment.html>