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

[David Owens]

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.

-David

> 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>