> On Mar 29, 2017, at 12:55 AM, Peter Dillinger <peter.dillin...@synopsys.com> > wrote: >>> On Mar 28, 2017, at 9:40 PM, Peter Dillinger <peter.dillin...@synopsys.com> >>> wrote: >>>> 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. >>> >>> Missing 'try' is a fatal issue? >> >> That could be argued I suppose, I was referring to unreachable code, unused >> variables, >> variables that are never mutated, etc. > > And what about non-exhaustive switch? > > Both of these existing rules seem to violate the principle claimed, because > they are hazards to incomplete or experimental changes that might lead people > to use quick fixes (try!; default) that are not associated with a warning, > whereas a warning instead of the error would (as you claim) signal to the > user there are pending fixes before commit. > > In theory, your position seems defensible, but I'm not seeing consistency in > application.
Non-exhaustive switch is like a missing return statement: the code isn't just "suspicious", it's potentially unsound if the warning is correct. That's not true of unreachable code or ignored return values. We could, of course, invent semantics for it, like implicitly asserting or implicitly falling through; but the former is inconsistent with our safety goals, and the second is likely to just lead to worse downstream diagnostics. You're correct that enforcing "try" as a hard error is not consistent with being lax about experimental code, but the entire point of "try" is to reliably mark places that can throw; making it only a warning would completely undermine that. If we had a language mode focused on experimental code, then yes, it would be appropriate to disable the "try" diagnostic; but adding a language mode like that would be really destructive long-term, outside of specific situations like coding in the debugger. I would say that the "incomplete" side of the coin is more important to us than the "experimental" side. We don't want laxer rules for experimental code because in practice there's usually no bright line between prototypes and production. But if our hand isn't being forced, and we don't have strong language-design reasons to enforce the rule, a warning is fine. John. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
