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

Reply via email to