<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">While I agree with most of your points Dave, I think forgetting to call super is very much a (hard to debug) real world problem today. Especially new developers seems unsure or likely to forget to call super when it is required.</div><div class=""><br class=""></div><div class="">I think my point is this; When you subclass code you have not written yourself you have no idea if the class you are subclassing is "poorly designed" and you should call super somewhere in your documentation. You can make assumptions, read the documentation or use trial and error, but there is no way to be certain unless the documentation is specific about it.</div><div class=""><br class=""></div><div class="">I went over the documentation for UIViewController. Is contains:</div><div class="">- 11 functions that specify that your subclass must call super during the implementation.</div><div class="">- 2 functions where the documentation specifies the default implementation is empty.</div><div class="">- 2 functions where you must not call super.</div><div class="">- 8 functions where you properly want to call super.</div><div class="">- 23 functions where I think there is no need to call super.</div><div class=""><br class=""></div><div class="">Based on the above I will admit that the default behaviour should properly be what we have today, but it would be lovely to have compiler warnings for the 11 functions that require it and the 2 functions where we should not call super.</div></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 29 Nov 2016, at 16.05, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">On Nov 29, 2016, at 1:48 AM, Tino Heth &lt;<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Methods that need to be called when they are overridden are</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">almost always a result of poor design.</span></div></blockquote></div>Without an explanation or data to back this statement, it's hard to argue about it, and I won't make random shots.&nbsp;<div class=""><br class=""></div><div class="">But as a matter of fact, we have to deal with methods which require the behaviour in question now, and I have no idea when Cocoa will be replaced with something better.</div></div></blockquote><div class=""><br class=""></div>That's a great point. &nbsp;I just don't want to punish those who create methods with default implementations that are designed to be completely replaced in subclasses. &nbsp;I suppose that *could* encourage more use of protocols, but that seems like a very unfriendly way to reach a protocol-oriented utopia&nbsp;<span style="background-color: rgba(255, 255, 255, 0);" class="">&nbsp;;-)</span><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="">Just out of sheer curiosity:</div><div class="">What would be a better design for a method like viewWillAppear? The obvious alternative that is possible with current Swift and template methods looks really ugly to me:</div><div class="">Not only would you have to add two empty methods to each subclass of UIViewController, </div></div></blockquote><div class=""><br class=""></div>Why two, and why empty? &nbsp;UIViewController would supply its own empty default implementation.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="">but also rely on that those methods are only overridden once in the hierarchy of inheritance.</div></div></blockquote><br class=""></div><div class="">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). &nbsp;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.</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>