<div dir="ltr">This is more of a developer practice that a team implements than an actual Swift/Xcode language feature. Also, I believe (not 100% sure) this wouldn't work for functions/properties that are dynamically dispatched. The compiler wouldn't know if the function will be called until runtime. </div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 11:15 AM, Charlie Monroe via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm personally -1 on this.<br>
<br>
I find it useful from time to time when debugging certain features - instead of commenting some part of code (and potentially forgetting to uncomment it), I wrap it in an "if false" statement - while I get a warning about the code not being reachable (or the if statement always evaluating to false), I can test your code and then go by the warnings and remove the "if false" statements.<br>
<br>
Similarly returning earlier. The warning is convenient as it warns you to review that part before releasing the code to the public.<br>
<br>
If we take into account the argument that people commonly ignore compiler warnings, we should enable "treat warnings as errors" by default - which I'm sure is not the correct way to go.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> On Mar 24, 2017, at 11:54 PM, Peter Dillinger via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I don't see anything directly relevant to this in the archives, and I haven't prepared a detailed proposal. But I'm raising the general idea because I recently criticized Swift 3 for allowing unreachable code in a blog post: <a href="https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/" rel="noreferrer" target="_blank">https://blogs.synopsys.com/<wbr>software-integrity/2017/03/24/<wbr>swift-programming-language-<wbr>design-part-2/</a> (search for "unreachable code"). And I want you to have every opportunity to rectify this, even though I'm in the business of finding defects the compiler doesn't. :)<br>
><br>
> Part of my argument is that people commonly ignore compiler warnings. We see lots of defective code that would be (or is) caught by compiler warnings but people don't pay attention.<br>
><br>
> If you would like to see more defect examples from open-source software (other languages for the moment), I am able to dig up such things.<br>
><br>
> Thanks<br>
><br>
> --<br>
> Peter Dillinger, Ph.D.<br>
> Software Engineering Manager, Coverity Analysis, Software Integrity Group | Synopsys<br>
> <a href="http://www.synopsys.com/software" rel="noreferrer" target="_blank">www.synopsys.com/software</a><br>
><br>
> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Joshua Alvarado<div><a href="mailto:alvaradojoshua0@gmail.com" target="_blank">alvaradojoshua0@gmail.com</a></div></div>
</div>