> On 24 Mar 2017, at 22:54, 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.
Which people? Personally warnings bug me no end; I'm not happy until they're all dealt with, so a warning is more than sufficient in my case. While obviously writing unreachable code on purpose isn't the best way to do something, sometimes throwing some code into an if (false) or dropping in an early return to see if it fixes or triggers a problem is a perfectly reasonable way to do something in a quick and dirty way. IMO a warning is more than sufficient for this, so that the programmer is reminded to go back and fix it. I don't know if it's possible to elevate specific warnings to errors (I used to do this working with Java in Eclipse but have never wanted to in Xcode), if not then that may be worth considering as an alternative? But as a default I think a warning is sufficient, at least for me, as I'd rather be able to make code unreachable than have an error when it is. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
