> On Oct 3, 2016, at 8:03 PM, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > > >> 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.)
This seems to me like the perfect answer for Swift. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
