FWIW also +1 for @frozen
(and actually +1 for everything Brent said)

On 21.12.2017 14:28, Jonathan Hull via swift-evolution wrote:
+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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to