> Why two, and why empty? UIViewController would supply its own empty default
> implementation.
The before/after pair: viewWillAppear would need a call to
"subclassViewWillAppear" (which would be empty in the declaring class, and need
a subsubclassViewWillAppear where it is overriden…) — and the same with
viewDidAppear.
For properties, Swift has a special mechanism that saves us from the need to
come up with names for new extension points (willSet/didSet), but there is no
equivalent for regular methods.
I'm not propagating the use of long inheritance chains, but a language imho
shouldn't try to educate its users by making it hard to use a paradigm it
claims to support.
> There's no law saying you *can't* call super if you absolutely must build a
> two-level hierarchy below UIViewController (though there are ways around
> that—the main one being to avoid inheritance hierarchies). I just don't want
> to create a world where you're always expected to call super everywhere,
> which is what would happen if we always warn when you don't call super.
I'm skeptical on adding more restrictions as well, so I guess I'd be fine with
"you have to call super" as opt-in. After all, it is less restrictive than
declaring everything final (which is a tiny bit safer, but much more limiting).
But afaics, no one has empirical data on how often each case (must call super,
must not call super, do as you like) happens...
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
