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