> On Dec 25, 2017, at 9:14 AM, Cheyo Jimenez via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> 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?
I would also expect case _ to only match known cases since _ acts like a wild char. switch x { // x is non-exhaustive here. case _ : fatalError("compile time error when missing cases ") // known cases at compile time default: fatalError("runtime error when missing cases") // unknown cases. } It makes sense for default and case _ to do the same thing for exhaustive enums but not for non exhaustive. Could this be addressed in the proposal too? Thanks in advance. > >>>> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution