[swift-evolution] Disallowing unreachable code
charlie at charliemonroe.net
Mon Mar 27 12:15:48 CDT 2017
I'm personally -1 on this.
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.
Similarly returning earlier. The warning is convenient as it warns you to review that part before releasing the code to the public.
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.
> On Mar 24, 2017, at 11:54 PM, Peter Dillinger via swift-evolution <swift-evolution at swift.org> wrote:
> 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: https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/ (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. :)
> 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.
> 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.
> Peter Dillinger, Ph.D.
> Software Engineering Manager, Coverity Analysis, Software Integrity Group | Synopsys
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution