I agree with everything said by Brent Royal-Gordon, however a -1 without the addition of a `future` case or something similar.
- What is your evaluation of the proposal? -1, this solution solves a real problem but introduces a very significant drawback. It should include a solution that preserves exhaustive pattern matching for the user. - Is the problem being addressed significant enough to warrant a change to Swift? Yes, absolutely. - Does this proposal fit well with the feel and direction of Swift? Feels like 1 step forward and 1 step back. Solves a real problem and introduces a real new one. - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? Rust settled on exhaustive as the default case, signaling the importance of preserving exhaustive pattern matching. I've run into bugs in Objective-C, where there is no exhaustive pattern matching, and that's been a pain - since enums are more powerful in Swift the consequences may be worse. - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I've actively participated in previous discussions on the topic, and read the proposal top-to-bottom for this review. I leverage enums and exhaustive pattern matching significantly in my own code. > On Dec 20, 2017, at 10: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 -- Rex Fenley | IOS DEVELOPER Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | FOLLOW US <https://twitter.com/remindhq> | LIKE US <https://www.facebook.com/remindhq>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution