>> On Mar 28, 2017, at 9:40 PM, Peter Dillinger <[email protected]> >> 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. -peter _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
