<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks for the response, Kevin. Xiaodi and others covered a lot of the points I would make but I'll add a few notes of my own.<div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 19, 2017, at 15:31, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 19, 2017, at 2:58 PM, Ted Kremenek <<a href="mailto:kremenek@apple.com" class="">kremenek@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote style="-webkit-print-color-adjust: exact; margin: 15px 0px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); padding: 0px 15px; color: rgb(119, 119, 119); font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class=""><div style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md</a></div></blockquote><ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">What is your evaluation of the proposal?</p></li></ul></div></div></blockquote></div><div class="">Overall I like it, but I have some issues.</div><div class=""><br class=""></div><div class="">I’m not completely sold yet on the idea that public enums should be non-exhaustive by default, as I believe every single public enum I’ve ever written definitely wants to be exhaustive. I’m tempted to say that enums exposed by frameworks that need to maintain future-compatibility (such as Apple’s frameworks) want non-exhaustive by default, but enums exposed by third-party frameworks that follow semantic versioning are likely to want exhaustive by default.</div><div class=""><br class=""></div><div class="">In fact, this brings to mind another difference between enums in Apple frameworks and enums in third-party Swift frameworks, which is the former is exclusively C-compatible enums whereas the latter is going to have a lot of enums that carry associated values. I have no data to support this but I’m inclined to think that it’s more likely for C-compatible enums to want to be non-exhaustive than it is for enums carrying associated values to want to be non-exhaustive.</div><div class=""><br class=""></div><div class="">So I guess I’m saying, I want more thought put on the topic of whether enums defined in Swift should actually default to non-exhaustive, and I’m now leaning towards the idea that they should remain exhaustive (but Obj-C enums will still default to non-exhaustive).</div></div></div></blockquote><div><br class=""></div><div>The main argument here for me isn't about frequency, although I like Brent and Sebastian's discussion about "three types of enums" (inherently exhaustive, non-exhaustive but useful to switch on, and things that are just inputs). What's most important here is that a library author who <i class="">doesn't</i> think about enum exhaustivity doesn't need to make a major-version release if they realize <i class="">either</i></div><div><br class=""></div><div>- they need a new case</div><div>- they meant to make the enum exhaustive</div><div><br class=""></div><div>Both of these are non-source-breaking changes as currently designed. In a world where enums are exhaustive by default, they would both be source-breaking. This is similar to 'open': if a library author just does the usual thing the language lets you do, they don't have to worry about clients doing something they didn't mean to allow.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">--</div><div class=""><br class=""></div><div class="">I don’t like that modules using @testable imports treat all enums as exhaustive. I can see why you want to do that, but being forced to handle non-exhaustive enums in unit tests seems like a valuable guard against accidentally publishing non-exhaustive enums that should be exhaustive.</div></div></div></blockquote><div><br class=""></div><div>This one's fair and I could go either way on it, but in practice my view is the same as Xiaodi's that it would be more annoying than useful. You can always import the library <i class="">without</i> using '@testable' in a different unit test source file.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">--</div><div class=""><br class=""></div><div class="">I’m really not a fan of using a ‘default’ case in non-exhaustive enums. This means that if new cases are added, the compiler can’t help me find my switches. I’d really like to have an alternative way of saying “here’s how to behave in the event of an unknown enum case” without also making that a catch-all for unspecified-but-known cases. You already brought up this issue in the alternatives section, where you stated</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Ultimately I decided not to include this in the proposal with the expectation is that switches over non-exhaustive enums should be uncommon.</blockquote></div><div class=""><br class=""></div><div class="">But since non-exhaustive enums will be the default, I think this _will_ become quite common, if for no other reason than you’re using a library written by someone who forgot to mark enums as @exhaustive that really should be.</div><div class=""><br class=""></div><div class="">Regarding the comment that a ‘future’ case is impossible to test, so is a ‘default’ case on a switch that is otherwise exhaustive. In the latter you can test it by commenting out one of your existing cases. But you can do that with ‘future’ too, just by renaming it to ‘default’ first.</div></div></div></blockquote><div><br class=""></div><div>Neither of those are tests that can be automated, though, right? I mean, I guess you could set up a "fallthrough if set" global or something…</div><div><br class=""></div><div>My response to Jerome goes into this a bit too: I'm not totally happy with what we have, but I'm not yet convinced the alternatives sufficiently solve the problem either.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">--</div><div class=""><br class=""></div><div class="">In the “Use-side” section it says that a switch without a default case will produce a warning in Swift 4 mode. But in Swift 4 mode all enums are exhaustive by default and the @exhaustive annotation does nothing. These two things can’t both be true or else Swift 4 mode will emit warnings on switches over enums that are very clearly supposed to be exhaustive enums.<br class=""></div></div></div></blockquote><div><br class=""></div><div>The change of C enums from exhaustive to non-exhaustive will apply to Swift 4 mode as well (and even Swift 3 mode, if that sticks around). The reason for this is that C enums with private cases are <i class="">very</i> broken right now: if an unexpected value makes its way into a switch in today's Swift, the behavior is undefined (as in, no guaranteed trap, no memory safety).</div><div><br class=""></div><div>If reviewers or the core team object to this part of the proposal, we would leave C enums as 'exhaustive' in Swift 4 mode, but at least make a switch over them deterministically trap if an invalid value shows up.</div><div><br class=""></div><div>Jordan</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Is the problem being addressed significant enough to warrant a change to Swift?</p></li></ul></div></div></blockquote><div class="">Yes</div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Does this proposal fit well with the feel and direction of Swift?</p></li></ul></div></div></blockquote>Yes<br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</p></li></ul></div></div></blockquote><div class="">A quick reading, followed by a few re-readings as I composed this email.</div></div><br class=""><div class="">-Kevin Ballard</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>