> On Dec 22, 2017, at 8:49 AM, Cheyo Jose Jimenez <ch...@masters3d.com> wrote: > > > >> On Dec 20, 2017, at 11:12 PM, Cheyo Jimenez <ch...@masters3d.com> wrote: >> >> >> >>> 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 >>> 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!
Preferably I’d like to say: switch (@exhaustive x){...} Would this be allowed? let @exhaustive myEnum= x typealias @exhaustive Y = X if let @exhaustive x = x { switch x {...} // exhaustive here. } Could this be addressed in the proposal? >>> 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@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