+1 for @frozen > On Dec 20, 2017, at 7:16 PM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >> <swift-evolution@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. > > 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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
