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

[Alexis]

> On Nov 30, 2016, at 5:02 PM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
> 
>> 
>> On Nov 27, 2016, at 16:32, David Sweeris via swift-dev <swift-dev at swift.org <mailto: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
> 

Idle thought: this discussion makes me think we might want a tristate for the different behaviours inside and outside the resilience domain:

* closed: inside and outside are exhaustive; always warn on dead defaults
* open: inside and outside are inexhaustive; never warn on dead defaults
* “default”: inside is exhaustive, outside is inexhaustive; warn inside, but not outside
(the hypothetical 4th state seems incoherent to me)

Basically the default behaviour is that I know what my enum is and would like the safety benefits of exhaustive matching, but I don’t want the evolution hazard of letting others exhaustively match. However I may also want the ability to be able to make certain enums act in-exhaustive even in my own code. This may be too niche to care about, though. Certainly this mode can be added later in a backwards compatible way.


> _______________________________________________
> 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/20161207/145c5738/attachment.html>