> On Nov 26, 2016, at 3:25 PM, Robert Widmann via swift-dev
> <swift-dev@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
