SE-0192 — Non-Exhaustive Enums — review #2

Evolution Proposal Reviews
61

I don't mean to answer the question with a question, but would you ask the Swift team why they're so intent on UIKeyboardType being an enum in Swift? I'm trying to understand why you're insisting on it not being an enum, because it sounds like what you consider to be poor advice should just as equally apply to every enum defined by Apple's Objective-C frameworks, right? Taking the above statement to its conclusion is saying that no enums from Foundation, UIKit, etc. should be imported into Swift as enums. But that's explicitly called out as a rejected alternative in the proposal (Import non-frozen C enums as RawRepresentable structs).

For the sake of argument, let's consider the ICU enum UWordBreakValues, which has had cases added to it over time. I want to use that enum (or one equivalent to it) as the return type for a property in Swift's standard library. Then, let's consider UIKit's UIKeyboardType, which has also had cases added to it over time. Can you explain why, if both of those C enums are exposed by a Swift library owned by Apple/the Swift team, they should be treated differently—one as an enum, and one not? I can't see why—either by your argument above, they should both be RawRepresentable structs, or they should both be enums.

1 Like
62

Accepted with Revision

The Core Team met on April 4, 2018 and decided to accept this proposal with revision.

Requested Revision

The only revision to Core Team decided upon was to not introduce a new context-sensitive keyword unknown but instead add an attribute @unknown to modify case and default respectively. Here is an example from the proposal that shows the original proposed syntax:

switch excuse {
case .eatenByPet:
  // …
case .thoughtItWasDueNextWeek:
  // …
unknown:
  // …
}

With the revision requested by the Core Team, the example would be written as:

switch excuse {
case .eatenByPet:
  // …
case .thoughtItWasDueNextWeek:
  // …
@unknown default:
  // …
}

The rationale is that behavior change is a modification of the behavior of default (i.e., issue a new warning) rather than a wholly new concept that would warrant a succinct keyword.

Further, the following syntactic synonym will also be accepted:

@unknown case _:

For the purpose of this proposal, the use of @unknown only applies to these two cases. Potential extensions, such as @unknown case (.foo, _), etc., are potential directions that can be explored in future proposals.

All other behavior outlined in the proposal will be accepted as is.

Remarks

This review took an unusually long amount of time and the community produced a tremendous amount of signal during the review of the proposal, including significant revision of the original proposal and a second run of the review. The second review also explored a variety of interesting options, including the proposed dedicated keyword, longer spelling of the suggested attributes, and other potential modifications to the language grammar. The final acceptance is based on both the intellectual and pragmatic weighing of the differ points presented.

Myself and the rest of the Core Team are grateful for all the energy that was poured into this review by the community.

19 Likes