> On Oct 3, 2016, at 9:39 AM, Robert Widmann via swift-evolution > <swift-evolution@swift.org> wrote: > > -1 in general. I want smarter exhaustiveness analysis, but I don’t want to > be able to ignore cases that “can’t happen” (so say we, writer of bugs) when > they’re clearly in the domain of possible values that can be fed to a > switch-case. Exhaustiveness guarantees wellformedness of a program that does > happen to go wrong, and makes it much easier to verify the correctness of the > flow of control of the containing block because all points from the switch > must be covered. We also don’t have the type-level tools to convince the > checker to allow you to remove unreachable cases. If it’s really a problem > that you are writing default cases everywhere, just bailout in a fatal error > with a nice description. It never hurts.
I can see the utility of a `switch!` construct that introduces the 'default: fatalError()' on your behalf. No matter how much analysis we do, there are always going to be cases with 'where' guards and expr patterns that we can't decidably analyze for exhaustiveness, for which runtime safety is the best we can offer. (That said, it'd fall squarely in the "sugar" bucket, so while it's an interesting idea to explore, it's not immediate Swift 4 Phase 1 material.) -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
