[swift-evolution] [Pitch] Can we make `default` on switches optional?

Matthew Johnson matthew at anandabits.com
Mon Oct 3 20:44:22 CDT 2016


> On Oct 3, 2016, at 8:03 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Oct 3, 2016, at 9:39 AM, Robert Widmann via swift-evolution <swift-evolution at 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.



More information about the swift-evolution mailing list