> On Mar 27, 2017, at 12:25 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Mar 24, 2017, at 6:54 PM, Peter Dillinger via swift-evolution >> <swift-evolution@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. > > It was, indeed, something of a policy goal for awhile to not have any > compiler warnings in Swift. The idea was that anything suspect should be an > error. We deliberately backed away from that because it was actually really > disruptive to the development experience: even very conscientious programmers > who diligently fix all their warnings sometimes have code "in flight", so to > speak, and want to be able to test and debug it without immediately making > invasive edits. To use a germane example, if unreachable code were always an > error, a programmer trying to debug a problem wouldn't be able to > short-circuit a function by just adding a return; they'd also have to comment > out the rest of the function. > > I think we're comfortable with the current balance. It's understood that > some programmers just ignore compiler warnings, but there are costs on the > other side, too.
+1. I like this being a warning for exactly the reasons you state. It’s very useful to sometimes be able to just insert an early return when debugging. > > John. > >> >> 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. >> >> Thanks >> >> -- >> Peter Dillinger, Ph.D. >> Software Engineering Manager, Coverity Analysis, Software Integrity Group | >> Synopsys >> www.synopsys.com/software >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
