Over five years have elapsed since the core team announced modifications to the implementation of SE-0192: Handling Future Enum Cases (aka Non-Exhaustive Enums).
Namely, the requirement to add an @unknown default case to handle future enum cases specifically for non-exhaustive enums was downgraded from "warning in Swift 4/error in Swift 5" to "trap-at-runtime in Swift 4/warning in Swift 5" in order to mitigate source compatibility impact.
To this day, it has remained the case that lack of an @unknown default case is a warning rather than an error; ignoring that warning means that a runtime trap occurs if a future enum case is encountered.
The language steering group discussed the current state of SE-0192 in light of our plans for the Swift 6 language mode, and we're announcing that we'll amend the proposal to:
- upgrade the warning to an error for Swift 6; and
- add an upcoming feature flag for Swift 5.x so that users can migrate their code incrementally.
As announced in our recent post on progress towards Swift 6, we have incorporated a number of source-incompatible changes using upcoming feature flags with the plan that these flags will be enabled by default in Swift 6. This approach to staging in source-incompatible changes was not available when SE-0192 was reviewed, but today we feel it is the most appropriate path—indeed, the only sensible way open to us—to complete this feature. We reached this decision considering several factors; among them:
-
It has been many years since the Swift 5 migration, and the warning has always been unsilenceable except by actually writing an
@unknown defaultcase. -
Ignoring the warning means leaving behind an implicit runtime trap if a future enum case is encountered—in the worst case, this behavior will remain trivially expressible in Swift 6 by writing something like
@unknown default: fatalError(), but when explicitly handled, users can opt for other default behaviors that make sense in context and don't require execution to be halted (for example, returningnil).
This limited amendment is independent of any orthogonal, additive work to enable non-extensible enums for non-resilient libraries.
— Xiaodi Wu, on behalf of the language steering group