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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
