[swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Sebastian Hagedorn]

+1 on @frozen and John’s reasoning.


> On 21. Dec 2017, at 04:32, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 	• What is your evaluation of the proposal?
>> 
>> I am pleased with the broad strokes of this design. I have quibbles with three areas:
>> 
>> 1. The `@exhaustive` attribute may be confusing because the term doesn't suggest versioning. My best alternative suggestion is `@frozen`, which matches existing programming terminology: something that has been frozen will not be changed in the future.
> 
> I rather like @frozen.  We could use that across language features, so that we don't end up with a keyword per kind of declaration.
> 
> John.
> 
>> 
>> 2. I think we need some kind of `future` keyword in `switch` statements. Even though a nonexhaustive enum may gain additional cases in the future, it's still useful for the compiler to diagnose that you forgot *known* cases.
>> 
>> You say that "switches over non-exhaustive enums should be uncommon", and this is true for many—perhaps most—non-exhaustive enums, but there is still a large class of non-exhaustive enums which need to be switched over. These are the ones I called "category 2" in my previous email in this thread. `SKPaymentTransactionState` is the example I previously used; others might include `Stream.Status` (if not exhaustive), `CLAuthorizationStatus`, `EKParticipantType`, `PKPaymentMethodType`, and `MKMapType`. Each of these could plausibly have more cases added; each has a good reason why you might switch over cases (such as display in a user interface); and each ought to be promptly updated when a new OS version introduces new cases. Without compiler assistance, those updates won't happen.
>> 
>> If we plan to add private cases in a future version of Swift, `future` may not be the best keyword. `unknown`, `invalid` (or `case #invalid`), etc. may be better.
>> 
>> 3. I am very skeptical of treating all enums as exhaustive if imported by `@testable import`. The only reason I can see not to do this is that forcing you to provide `default` might hide tests that need to be updated for new enum cases—but this is the exact problem that `future` is trying to solve. By contrast, treating them as non-exhaustive forces you to actually notice when an enum is published as nonexhaustive and consider whether that's the right approach.
>> 
>> None of these are showstoppers if left unaddressed, but I think the design would be better if we fixed them.
>> 
>>> 	• Is the problem being addressed significant enough to warrant a change to Swift?
>> 
>> Yes. I have no idea how Swift programs currently behave when a future framework version adds a case, but I can't imagine they do anything good.
>> 
>>> 	• Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes, with the exception of conflating `default` and `future`, which removes useful correctness checks.
>> 
>>> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> 
>> I've experienced bugs in Objective-C caused by the compiler not knowing an enum might have additional, unknown cases. Debugging them sucked.
>> 
>>> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
>> I've participated in multiple rounds of discussion on this topic, and read the proposal top-to-bottom for this review.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171221/4a06237d/attachment.html>