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

David Owens owensd at apple.com
Thu Dec 21 15:11:43 CST 2017

I very much agree with the high-level of the proposal. The concept definitely needs to exist. However, I feel that the options presented do so in a non-intuitive way.

There are two concepts here: closed and open listing of values that make up a set of possible options to be used. I think of this much like struct vs. class in terms having to determine conceptually which is the right approach for the problem you are solving. As such, I feel that this is a significant enough difference between the concepts that it warrants a declarative difference via a keyword, not just some annotation.

Further, for me personally, putting conditional differences on access level has always been a very annoying and frustrating experience in Swift, and this adds to that. Using a keyword to distinguish helps with that.

I don’t know the best spelling for, but I’d want something like this:

enumset GregorianWeekday
    case monday // ISO 8601 says weeks start on Monday
    case tuesday
    case wednesday
    case thursday
    case friday
    case saturday
    case sunday

That’s the exhaustive list, no others can be added. Access level does not matter.

enum Emotions
    case happy
    case sad
    case angry

This is a non-exhaustive list. Others can be added via extensions. Access level does not matter.


> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution <swift-evolution at swift.org> 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 <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 <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 <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 mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

More information about the swift-evolution mailing list