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

[Goffredo Marocchi]

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 <swift-evolution at swift.org> wrote:
> 
> 
>> 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.
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution