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

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


> On Nov 26, 2016, at 3:25 PM, Robert Widmann via swift-dev <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.

This is not quite right. The totality checker only kicks in if the module containing the enum is not built with resilient interfaces. When built with resilience enabled (you can pass —swift-stdlib-enable-resilience=1 to build-script), the warning is gone, and the default case is required; without it, you get an error about a non-exhaustive switch.

>  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.

One workaround would be to define ProcessTerminationStatus as @_fixed_layout, but that attribute is not documented right now. The eventual goal is that the attribute will be renamed to @closed for enums, and the warning will be emitted even if the module was built non-resiliently.

However there’s a chance that at some point we will also be building the stdlib with resilience enabled by default, but I can’t comment on what the plans are in this area yet.

> 
> I’ve filed SR-3278 <https://bugs.swift.org/browse/SR-3278> to track this as well.
> 
> Thanks,
> 
> ~Robert Widmann
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> 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/446e9af1/attachment.html>


More information about the swift-dev mailing list