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