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

[Rex Fenley]

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 at swift.org> wrote:
>
>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution <
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.
>
> 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

-- 

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171221/d9374ac8/attachment.html>