<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=""><div class="">Hi Jordan,</div><div class=""><br class=""></div><div class="">Upon further reflection, I’m going to withdraw my concerns about the defaulting and I think it’s the right solution after all. This is due to several thoughts I had rolling it around my head:</div><div class=""><br class=""></div><div class="">1. In a private project, you would expect all cases to be exhaustive, as this is guaranteed by the compiler (no compatibility concerns). Exhaustive makes sense here, as it has always done in Swift code, and is why it was the behaviour since Swift 1.</div><div class="">2. When we make projects public, we already need to vet them for compatibility concerns with final etc. This should be part of the process of making them public.</div><div class="">3. It's source compatible with libraries, as mentioned in the proposal.</div><div class=""><br class=""></div><div class="">I can imagine there will still be a tonne of work needed for apps compiling against Apple’s Obj-C SDKs when Swift 5 comes out due to this change. Almost all enums will become <font face="Menlo" class="">nonexhaustive</font>, but this will then show up in documentation changes, header updates etc, and as you’ve mentioned, it will avoid confusion.</div><div class=""><br class=""></div><div class="">Sorry! I think I just needed some time to roll it around my head a bit haha</div><div class=""><br class=""></div><div class="">- Rod</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 6 Sep 2017, at 10:47 am, Rod Brown 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="">Ah yes, my eye skipped that alternative for some reason! Sorry.<div class=""><br class=""></div><div class="">I’d be concerned that avoiding a default is a fix for a compatibility problem, not a language design decision. If we look back in 5 years and say “why do we need to keep writing nonexhaustive everywhere?”, we’ll have to say “there were compatibility problems with Swift 4-to-5”. That reeks of a language I just want to walk away from. Yuk.</div><div class=""><br class=""></div><div class="">In this case, either way, we’ll need to do some work. So why not let the migrator migrate this code correctly to “exhaustive”, which is the current behaviour? I think a decision where either way we break source compatibility should be done in the interest of language design, not in the short term interest of avoiding confusion.</div><div class=""><br class=""></div><div class="">But that’s just my 2c.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">Rod</div><div class=""><br class=""></div><div class=""> </div><div class=""><div class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 6 Sep 2017, at 10:36 am, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.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; line-break: after-white-space;" class=""><div class="">It's in the "Alternatives Considered" section. :-) That was my desired design when we started, but feedback convinced me that the break from Swift 4 mode would be too drastic. The same valid code would have a different meaning whether you were writing Swift 4 or Swift 5.</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 5, 2017, at 17:30, Rod Brown <<a href="mailto:rodney.brown6@icloud.com" class="">rodney.brown6@icloud.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; line-break: after-white-space;" class="">Hi Jordan,<div class=""><br class=""></div><div class="">I’m not sure how much bearing on this my comment will have.<div class=""><br class=""></div><div class="">Have you considered having only “exhaustive” as a keyword, and make the default non-exhaustive? It seems that “exhaustive" would be the rarer case, as it promises a lot more about compatibility (much like there is no such thing as “non-final”). Also, non exhaustive seems a massive mouthful despite it probably being the correct term.</div><div class=""><br class=""></div><div class="">- Rod</div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 6 Sep 2017, at 10:19 am, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.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; line-break: after-white-space;" class=""><div class="">I've taken everyone's feedback into consideration and written this up as a proposal: <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>. The next step is working on an implementation, but if people have further pre-review comments I'd be happy to hear them.</div><div class=""><br class=""></div><div class="">Jordan</div></div></div></blockquote></div></div></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></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></div></body></html>