+1 on @frozen and John’s reasoning.
> On 21. Dec 2017, at 04:32, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >>> <swift-evolution@swift.org <mailto: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. > > 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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
