[swift-evolution] Getting rid of willSet/didSet

[Tino Heth]

> I’m not sure I understand your example. `super` is a reference to the superclass implementation of `foo`, but `UIView` doesn’t declare a property called `foo`. 
It’s quite simple: „super“ is just a string that can have a special meaning for the tokenizer, and normally, we read it as „please do what the class I’m inheriting from would do“ — but you could as well interpret it as „do what would happen if my implementation didn’t exist“, which has a slightly wider scope.

In the old dark ages, when properties with todays comfort didn’t exist, the only thing we could do was declare a pair of methods to read and write a field. Those are boring, but under the hood, they are still there, lurking in a dark thin layer in the hierarchy of inheritance.
Of course, the method that actually copies the bytes of class Bs instance variable „foo“ doesn’t belong to Bs parent A, so with the narrow interpretation of super, there is no way to utilize the nifty helper method that is created for us: When we write our custom accessor for foo, it is overwritten, and there is no path to reach it… unless we add our setter in subclass C, where Bs syntax problem disappears, and „super.foo“ connects us to those helper methods.

The alternative to subclassing is creating a backing field, just like old Objective-C did, and even a young language like Kotlin has something similar (afaik it is more secure, and $foo only exists in foos accessor). Swift, on the other hand, shirks the problem by introducing of a whole set of new keywords that aren’t useful anywhere else.

Guess I should have started this small discussion coming from the other direction: Seems I just created refusal by „attacking“ a tiny useful feature, instead of writing about the benefits that NS_REQUIRES_SUPER has to offer in the first place, and reach the conclusion that it can make existing constructs obsolete when everyone is thrilled about the potential advantages… so, maybe we could forget about the subject of this message and argue about the pros and cons of that cool attribute? ;-)