I'm also against this (though I like the first alternative about warning on
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.
On Thu, Dec 1, 2016 at 3:40 AM Tino Heth via swift-evolution <
> 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
> swift-evolution mailing list
swift-evolution mailing list