[swift-evolution] Disallowing unreachable code

[Chris Lattner]

> On Mar 27, 2017, at 10:25 AM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Mar 24, 2017, at 6: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.
> 
> 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.

Agreed, we have the right design here.  The go community has shown the result of taking a hard line on this, and it really hurts refactoring and other experimental “pound out some code” prototyping use cases.  We use warnings for things that “should be cleaned up before code is committed”, but which is not itself a fatal issue.

-Chris