[swift-dev] [Pitch] Remove "Default will never be executed" Warning?

Slava Pestov spestov at apple.com
Sun Nov 27 22:06:58 CST 2016

> On Nov 27, 2016, at 4:32 PM, David Sweeris via swift-dev <swift-dev at swift.org> wrote:
>> On Nov 26, 2016, at 5:25 PM, Robert Widmann via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> Hello all,
>> I’ve seen and been a part of a number of conversations recently where talk of planning for “resilient enums”, or even just authors that ship frameworks that will eventually offer a binary option that export enum-based APIs.  The consensus seems to be that the only safe way to deal with this situation is to always cover a `switch` statement with a default, regardless of whether the totality checker thinks you’ve covered all cases.  Currently, the compiler warns when this is the case, as in stdlib
>> extension ProcessTerminationStatus {
>>   var isSwiftTrap: Bool {
>>     switch self {
>>     case .exit(_):
>>       return false
>>     case .signal(let signal):
>>       return CInt(signal) == SIGILL || CInt(signal) == SIGTRAP
>>     default:
>>       // This default case is needed for standard library builds where
>>       // resilience is enabled
>>       return false
>>     }
>>   }
>> }
>> I think this warning doesn’t actually serve a purpose and I’d like to remove it, or at the very least curb it.  Currently, I see three paths forward:
>> 1) Do nothing.
>> 2) Completely remove the diagnostic
>> 3) Only emit the diagnostic when the case-tree is switching over enum(s) declared inside the current module.
> Has the “resilient enum” thing been finalized, or is this kind of code just a preventative measure?
> Also, if “resilience” is a compiler flag, there's a fourth option: Disable the warning on builds that have “resilience” enabled.

The warning is already gone (and the default cause is required) when the standard library and overlays are built with resilience enabled. The issue is that resilience is off by default.

I agree the warning is annoying; we should figure out something.

> - Dave Sweeris
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org <mailto:swift-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161127/2e652530/attachment.html>

More information about the swift-dev mailing list