<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>On 18 Sep 2017, at 19:20, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8">That's pretty much the same as this proposal except you don't have the new keyword. I'm not sure why that really makes a difference, since they're obviously paired, and it would limit existing libraries from declaring exhaustive enums until they've moved entirely to Swift 5 mode. I think the current proposal makes sense as is.</div></blockquote><div><br></div><div>The difference is that it reduces the keyword soup and removes a keyword that will be the default behavior enums have in Swift 5. If we follow the same reasoning, why don’t we have nonfinal, @nonescaping, @nonDiscardableResult? Is it really worth adding a keyword only to support libraries while they transition to Swift 5?</div><br><blockquote type="cite"><div><div class="">Jordan<br class=""><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 16, 2017, at 01:55, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</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; -webkit-line-break: after-white-space;" class=""><div class="">I’m still very much bothered by having 2 new keywords. I would really prefer the following plan:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Exhaustive by default in Swift 4</li><li class="">No new keyword in Swift 4 to change that behaviour</li><li class="">Non-exhaustive by default outside the module in Swift 5</li><li class=""><b class="">exhaustive</b> keyword to change the default behaviour</li></ul><div class=""><br class=""></div></div><div class="">Like that, we don’t need <b class="">nonexhaustive</b>.</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class="">David.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 13 Sep 2017, at 21:16, Jordan Rose 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; -webkit-line-break: after-white-space;" class=""><div class="">Proposal updated, same URL: <a href="https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md" class="">https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md</a>.</div><div class=""><br class=""></div><div class="">Thanks again for all the feedback so far, everyone!</div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 12, 2017, at 17:55, Jordan Rose 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=""><div class="">Sorry, I got distracted by other tasks! Both the discussion here and within Apple has moved towards making "non-exhaustive" the default, which, to be honest, I too think is the best design. I'll update the proposal today to reflect that, though I still want to keep both the "nonexhaustive" and "exhaustive" keywords for Swift 4 compatibility for now (or whatever we end up naming them). The compatibility design is a little less ambitious than Brent's; as currently proposed, Swift 4 mode continues to default to 'exhaustive' all the time, even in the actual Swift 5 release.<br class=""><br class="">I still want to respond to Brent's points directly, but I think you and Vladimir have done a good job discussing them already. I'll send out the updated proposal tomorrow, after I have a little more time to think about #invalid.<br class=""><br class="">Thanks for putting time into this!<br class="">Jordan<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Sep 9, 2017, at 17:34, Rod Brown <<a href="mailto:rodney.brown6@icloud.com" class="">rodney.brown6@icloud.com</a>> wrote:<br class=""><br class="">Jordan,<br class=""><br class="">Do you have any other thoughts about the ongoing discussion here, especially regarding Chris’ comments? As you’re the one pushing this forward, I’d really like to know what your thoughts are regarding this?<br class=""><br class="">- Rod<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></body></html>