<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Thanks for your thoughts.</div><div class=""><br class=""></div><div class="">I think 3) is indeed a very common case, but also not affected by this proposal or the general issue at all. Unless I’m missing something, I think it makes sense to limit the discussion to those enums that are typically switched over in client code.</div><div class=""><br class=""></div><div class="">I don’t think 1) outnumbers 2), which is exactly why I think it is important to have some sort of exhaustive-checking for 2). If 2) was an edge cases, I wouldn’t mind, because 1) behaves the same way with or without the implementation of this proposal.</div><div class=""><br class=""></div><div class="">What I was trying to say is: 99% of the times I switch over an enum, I do want to consider all available cases in my code, which also means I want to be informed (by a warning) if I’m missing something. Without anything like `future`, I’ll end up with switches that used to be exhaustive, but are not anymore when the library author adds a case, and I don’t learn about it until I hit such a case at runtime (documentation aside), which may rarely happen. I’m aware that there may be a period of time during which I haven’t updated my code and my code has to deal with unexpected cases, but as soon as I get to compile my code with the current SDK, I’d like to learn about new cases.</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 20. Dec 2017, at 11:39, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><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 class="">Is that typical of your interactions with, say, `UIViewAnimationTransition`?</div><div class=""><br class=""></div><div class="">There are three categories of enums in the SDK:</div><div class=""><br class=""></div><div class=""><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 class=""><br class=""></div><div class=""><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 class=""><br class=""></div><div class=""><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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><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 class=""><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></div></div></blockquote></div><br class=""></body></html>