<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 1:00 AM, Sebastian Hagedorn via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><span class="" style="color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; background-color: rgb(255, 255, 255);"> The expectation is that switches over non-exhaustive enums are uncommon.</span></blockquote></div><div class=""><br class=""></div><div class="">Basically every time I interact with an enum, I switch over it, to make sure I don’t forget anything, and to make sure I reconsider my code if the library changes. Since most SDK enums will become non-exhaustive, this is the 99% case for me.</div></div></div></blockquote><br class=""></div><div>Is that typical of your interactions with, say, `UIViewAnimationTransition`?</div><div><br class=""></div><div>There are three categories of enums in the SDK:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>1) Those which you switch over and which are inherently exhaustive. For example, `ComparisonResult` will never, ever have a case besides `orderedAscending`, `orderedSame`, and `orderedDescending`. All possible values fit into one of these three categories (other than those for which comparison is not a valid operation). You want an exhaustive switch for these.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>2) Those which you switch over but which could have cases added in the future. For example, `SKPaymentTransactionState` (representing the state of an in-app purchase) may sometimes need additional cases; one was already added in iOS 8 for a parental permission feature. You want a nonexhaustive switch for these, with a `default` clause containing some fallback behavior (like skipping the associated entry or showing an error message).</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>3) Those which you almost never switch over at all; they are simply used as opaque inputs to APIs in the same framework. For example, very few pieces of code ever need to examine or use a `UIViewAnimationTransition`; they just need to pass one into the proper UIKit animation APIs. (Error types are another example—you should catch specific errors you know you want to handle specially, but you should never imagine that you have thought of all possible errors.) You basically don't care about the switch behavior of these enums; the compiler could even ban switching over them and you would probably never notice.</div><div><br class=""></div><div>Category 1 enums should be exhaustive; category 2 and 3 should be nonexhaustive. So the question is, do category 1 enums outnumber category 2 and 3? You seem to suggest that they do, but I very much doubt that. My suspicion is that category 3 is the most common, followed by category 2, with category 1 bringing up the rear. The authors of the proposal say they surveyed Foundation enums to test this theory:</div><div><br class=""></div><div><blockquote type="cite" class="">To see how this distinction will play out in practice, I investigated the public headers of Foundation in the macOS SDK. Out of all 60 or so NS_ENUMs in Foundation, only 6 of them are clearly exhaustive:<br class=""><br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• ComparisonResult<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• NSKeyValueChange / NSKeyValueSetMutationKind<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• NSRectEdge<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• FileManager.URLRelationship<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• maybe Decimal.CalculationError<br class=""></div><div><br class=""></div>...with a handful more that could go either way, such as Stream.Status. This demonstrates that there is a clear default for public enums, at least in Objective-C.<br class=""></blockquote><br class=""></div>Maybe a survey of another library like Alamofire would show different results; if you think it would, by all means feel free to demonstrate it.<div class=""><br class=""></div><div class="">Having said that, I too think that `future` or `unknown` is a good idea, and I think we should strongly consider adding it. Doing so would restore many of the correctness benefits of exhaustiveness checking to nonexhaustive enums, significantly reducing the painful parts of this feature.<br class=""><div class=""><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></div></div></body></html>