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

[Cheyo Jose Jimenez]

> On Dec 20, 2017, at 11:12 PM, Cheyo Jimenez <cheyo at masters3d.com> wrote:
> 
> 
> 
>> 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
>> 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?
>> 
> +1 except for the name. @frozenExposed @fixedMembers @frozenMembers. 
> preferably something that aligns with the other notion of not being able to add public members to structs. This will help treat structs with static members in the same way which would be ideal.  I don't think enums should have their own attitude.
>> Is the problem being addressed significant enough to warrant a change to Swift?
>> 
> don't know. im not a library author. ill defer to other library authors. 

I want to revise my review here. While I am not a library author I am a library consumer. 

Having the ability treat a non exhaustive enum as exhaustive should be introduced with this. I like the idea of a 
`final switch`

I think it communicate clearly that I want this to be treated as exhaustive even if it is already exhaustive. Having something like future, unknowns would be weird to me. 

Another option would be being able to cast a enum as exhaustive. I am not sure how that would work. I do not like switch!  

>> Does this proposal fit well with the feel and direction of Swift?
>> 
> yes. 
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> 
> n/a
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
> followed the previous discussion. read the proposal. 
>> 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/20171222/93cd2bf1/attachment.html>