The best answer is always "that would be an ecumenical matter...". It works here too ;).
Sent from my iPhone > On 4 Oct 2016, at 03:44, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > >> On Oct 3, 2016, at 8:03 PM, Joe Groff via swift-evolution >> <[email protected]> wrote: >> >> >>> On Oct 3, 2016, at 9:39 AM, Robert Widmann via swift-evolution >>> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
