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

[Jordan Rose]

> On Nov 27, 2016, at 16:32, 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.

This issue isn't really specific to resilience. If you depend on some third-party library through the Swift package manager, that library should be free to add new cases to enums in new releases without that being a source-breaking change. On the other hand, maybe you do want to know when new cases are added, so you can go update your switch statements as the author of the client.

There hasn't been any formal proposal for open vs. closed enums yet. Today all Swift enums are treated as closed, while imported C enums are sometimes treated as closed (switch) and sometimes as open (init(rawValue:) always succeeding). The Library Evolution document <http://jrose-apple.github.io/swift-library-evolution/#enums> describes how we want enums to behave in a resilient library, but doesn't discuss non-resilient source packages.

I'd lean towards (3) as the right answer for now, but it would also be great to start the ball rolling on designing a "closed" annotation for enums that makes sense for both source and binary distribution.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161130/7ce61f0e/attachment.html>