<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="">+1, and I would add that I don’t consider adding a "silence warning" attribute a valid solution to avoid a warning.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 26 févr. 2016 à 16:50, Vanderlei Martinelli via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">@Step: I agree with you. I just cannot ignore a single warning and I'm not happy until my project compiles without errors *and* without any warnings.<div class=""><br class=""></div><div class="">-Van</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Feb 26, 2016 at 10:28 AM, Step C via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">I keep seeing the argument made that people can just ignore warnings so it does not stop them. I think that is a misuse of warnings. We should not be providing warnings that we expect some people to just ignore. Further, at many places warnings are treated the same as errors. <br class=""></div><div class=""><br class=""></div><div class="">- Step</div><div class=""><div class="h5"><div class=""><br class="">On Feb 25, 2016, at 5:02 PM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 25 Feb 2016, at 15:47, Jeremy Pereira via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><br class="">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:<br class=""><br class=""> override func viewDidLoad()<br class=""> {<br class=""> print(“About to run super.viewDidLoad()”)<br class=""> super.viewDidLoad()<br class=""> print(“Finished super.viewDidLoad()”)<br class=""> }<br class=""><br class="">Then there’s the perfectly reasonable case like this:<br class=""><br class=""> override func viewDidLoad()<br class=""> {<br class=""> functionThatCallsSuperViewDidLoad()<br class=""> }<br class=""><br class="">Why shouldn’t I be allowed to do that?</div></blockquote><br class=""></div><div class="">Because the parent class told you not to? I’ve said repeatedly on the subject now however that before/after constraints aren’t something that you should expect to see commonly, as they’re something that developers should only set if they are absolutely certain that they will be required. The way I see it they will be most commonly used in two particular cases:</div><div class=""><br class=""></div><div class=""><ul class=""><li class=""><b class="">Partial Implementation:</b> For an abstract-style class, a provided partial implementation might only handle the preliminary setup or final handling of values, in which case it must be called first or last in order for an implementation to be completing it correctly.</li><li class=""><b class="">Undefined State:</b> If the parent class shares values and methods for sub-classes to use, but cannot guarantee a consistent state if they are called without the super method. Again this is really more likely to happen in types that are specifically intended for extension where order may be important, rather than a complete type that you just happen to decide to extend.</li></ul><div class=""><br class=""></div><div class="">To reiterate, these should one of the less commonly used operations, and since the default is going to be to issue a warning then <b class="">you aren’t prevented from doing anything</b>.</div><div class=""><br class=""></div><div class="">It’s also possible that if the compiler can better detect “mutating” class methods then it would be possible for it to allow non-mutating code in front of a before condition, though could still potentially need to be warned against (in the undefined state you could be retrieving a value before it’s ready to be used). But once again, it’ll be a warning, so you can just ignore, and that’s assuming the condition is even being used, which shouldn’t be very common if it’s being used sensibly.</div></div></div></blockquote></div></div><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><span class=""><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></span></div></blockquote></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></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=""></div></body></html>