[swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums
sebastian at iosphere.de
Wed Dec 20 06:43:20 CST 2017
Thanks for your thoughts.
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.
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.
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.
> On 20. Dec 2017, at 11:39, Brent Royal-Gordon <brent at architechies.com> wrote:
>> On Dec 20, 2017, at 1:00 AM, Sebastian Hagedorn via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> The expectation is that switches over non-exhaustive enums are uncommon.
>> 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.
> Is that typical of your interactions with, say, `UIViewAnimationTransition`?
> There are three categories of enums in the SDK:
> 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.
> 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).
> 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.
> 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:
>> 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:
>> • ComparisonResult
>> • NSKeyValueChange / NSKeyValueSetMutationKind
>> • NSRectEdge
>> • FileManager.URLRelationship
>> • maybe Decimal.CalculationError
>> ...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.
> 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.
> 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.
> Brent Royal-Gordon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution