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

[Chris Eidhof]

I can see why this is useful, and understand the problem. However, it does
feel like the wrong solution to a real problem. This seems to be very
similar to the *expression problem*:

> The expression problem is a new name for an old problem.[2][3] The goal
is to define a datatype by cases, where one can add new cases to the
datatype and new functions over the datatype, without recompiling existing
code, and while retaining static type safety (e.g., no casts).
>
> (source: https://en.wikipedia.org/wiki/Expression_problem)

The price we'll pay for this proposal is to always have a default case with
non-exhaustive enums. To me, this feels very similar to the default case in
Swift's error handling, and in that sense it matches the existing language
behavior. However, I find the default case in Swift's error handling quite
annoying (especially if you can guarantee you've handled all possible
errors).

In the case of enums, I'd much rather get a compiler error because I didn't
handle case, than a runtime error because my default caught a case I
actually wanted to catch. Having non-exhaustive enums makes it much harder
to refactor code that uses those enums (if I add a case, the compiler
doesn't give me a list of all the sites I need to fix).

A -1 from me.

I would like a solution to the problem, but I feel that the proposed
solution has too many drawbacks.


On Tue, Dec 19, 2017 at 11:58 PM, Ted Kremenek <kremenek at apple.com> wrote:

> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through *January
> 3, 2018*.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0192-non-exhaustive-enums.md
>
> Reviews are an important part of the Swift evolution process. All review
> feedback should be sent to the swift-evolution mailing list at:
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> When replying, please try to keep the proposal link at the top of the
> message:
>
> Proposal link: https://github.com/apple/swift-evolution/blob/master/
> proposals/0192-non-exhaustive-enums.md
> ...
> Reply text
> ...
> Other replies
>
> What goes into a review of a proposal?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift.
>
> When reviewing a proposal, here are some questions to consider:
>
>    -
>
>    What is your evaluation of the proposal?
>    -
>
>    Is the problem being addressed significant enough to warrant a change
>    to Swift?
>    -
>
>    Does this proposal fit well with the feel and direction of Swift?
>    -
>
>    If you have used other languages or libraries with a similar feature,
>    how do you feel that this proposal compares to those?
>    -
>
>    How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
>
> Thanks,
> Ted Kremenek
> Review Manager
>
> _______________________________________________
> swift-evolution-announce mailing list
> swift-evolution-announce at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
>


-- 
Chris Eidhof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171221/d9e2eff7/attachment.html>