<html><body><div>didSet/willSet is super handy for doing things like updating UI when a property has been set without going through the overhead of writing a full setter or getter. It's useful for many things beyond a super class responding to changes going through a subclass.</div><div><br data-mce-bogus="1"></div><div>Blocking/validating changes seems like something totally different to me. didSet/willSet doesn't really seem meant for change validation necessarily, and I think it's mixing use cases. That almost seems like something where you'd want to move beyond properties (Obj-C certainly doesn't handle validation in this way.)</div><div><br>On Dec 14, 2015, at 02:57 PM, Tino Heth via swift-evolution &lt;swift-evolution@swift.org&gt; wrote:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content">Hi there!<br><br>Considering that I just read that someone wants to have „willGet“, I guess willSet and didSet are here to stay — but for me, the concept has several downsides:<br>- two special keywords<br>- oldValue as another special word (there are some of those, but afaics only self and super are used often)<br>- imho it is not intuitive in which order those methods are called when subclassing<br>… and all those special rules only work for properties.<br><br>I think NS_REQUIRES_SUPER (beside the hard name) is much better, because<br>- it works for every method (I guess everyone knows some classes in Cocoa where the docs say you must call super, but the compiler cannot enforce this)<br>- order of execution is clear<br>- it is easy to block a change, instead of doing a rollback in „didSet“<br><br>The only advantage of willSet/didSet is that it is easy to create a stored property and be notified when it is changed, without the need to create an additional field — but I think it wouldn’t be that bad to just write „super.property = value“, even if there is no superclass as backing store: It may appear odd, but shouldn’t cause any problems.<br><br>Best regards,<br>Tino<br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></div></blockquote></div></body></html>