Thanks for the replies.
Kenny: After thinking about it more, discussing with Peter, and looking Haravikk’s comments, I think the best thing would be for this to be a warning as suggested. I respectfully disagree that as a library creator you would not be able to know that a call to super should be required.
I disagree. You can’t possibly know all the use-cases in which your class might be subclassed.
+1
In particular, it is absurd to enforce having the call to super as the first or last line of the method. That would stop me doing things like this:
override func viewDidLoad()
{
print(“About to run super.viewDidLoad()”)
super.viewDidLoad()
print(“Finished super.viewDidLoad()”)
}
+1
Then there’s the perfectly reasonable case like this:
override func viewDidLoad()
{
functionThatCallsSuperViewDidLoad()
}Why shouldn’t I be allowed to do that?
I would consider that a code smell (calling a super method from within a different method), because when this is allowed I can start to call super methods from methods which are not themselves called by the overriding method and that makes it difficult when changing the implementation of the overriding method, because then I have to hunt down whether the super method might be called somewhere else and think about whether that is still appropriate.
I’m not a fan of "final by default” either because people will leave the virtual (or whatever is called) keyword off through laziness, not because it is definitely impossible to override the method or or subclass the class and make their classes impossible to reuse.
+1
-Thorsten
···
Am 25. Februar 2016 um 16:58 schrieb Jeremy Pereira via swift-evolution swift-evolution@swift.org:
On 17 Feb 2016, at 22:26, Kyle Sherman via swift-evolution swift-evolution@swift.org wrote: