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

[Derrick Ho]

I like this proposal!

+1

Oldvalue and newvalue have different meanings. I have witnesses programmers
overriding oldvalue with the name newvalue and vice versa.

Of course if you are good at reading the documentation then you would not
make the mistake.

Swift should be a language that prevents a programmer from making mistakes!

I am in favor of disallowing the name changes. Because it is much more
clear if it is an oldvalue or newvalue.

If a different name is desired there are two solutions, create a new
variable or add a capture list.

set (newValue: TheType) {
let temp = newValue
}

set { [temp = newValue] in

}

I think either of these would make this change easier to convert.

The second one would probably be easier to convert.

//current
set (temp) {

}

// Proposed and much more clear.
set { [temp = newValue] in

}

On Thu, Dec 1, 2016 at 3:01 PM Will Field-Thompson via swift-evolution <
swift-evolution at swift.org> wrote:

> I'm also against this (though I like the first alternative about warning
> on set(oldValue) etc.).
>
> While I think there may be value in either preventing name overrides or
> requiring them here, I don't believe it's worth a breaking change. Then
> again, I have never personally encountered the problem (I tend not to
> override names), so maybe those who have feel differently.
>
> I also think that if this proposal goes through I would prefer not to
> allow the current name overriding syntax, even in the self-documenting
> case. At that point, the self-documenting case seems like unnecessary
> syntactic noise. It makes sense for a team where observer names are
> frequently overridden, but when that's disallowed, I feel that the
> self-documenting case adds very little.
>
> - Will
>
>
> On Thu, Dec 1, 2016 at 3:40 AM Tino Heth via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> -1
>
> I'm more or less neutral towards the change itself, but combined with the
> breaking effect, that's a clear "no".
>
> None the less, I hope that the whole topic with all its magic words
> (willSet, didSet, newValue, oldValue…) will be reworked in the future,
> which would be another argument not to fiddle with it now*
>
> - Tino
>
> *
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003148.html
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/20161202/3cc3670f/attachment.html>