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