<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 22. Sep 2017, at 17:21, Karl Wagner 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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On 21. Sep 2017, at 00:51, Rex Fenley 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 dir="ltr" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Hi Jordan,<br class=""><br class="">I've been keeping up with most of the discussion since I last emailed about my concern about making nonexhaustive the default mode for enums. So far I am still strongly in the camp of exhaustive by default.<br class=""><br class="">Most of my understanding comes from the perspective of source compatibility; since I'm primarily an iOS app developer and contributor to open source through CocoaPods, I don't have enough experience with binary compatibility issues to understand the breadth of the effects of such a change on binary compatibility - so I will argue from the perspective of source compatibility. Additionally, all the following applies exclusively to enums from Swift and not Obj-C/C. Largely my concerns stem from the<a href="https://en.m.wikipedia.org/wiki/Default_effect_(psychology)" class=""> "default effect</a>"- whatever default is chosen is going to unconsciously bias developers to use that default.<br class=""><br class="">To start, I don't follow how nonexhaustive by default leads to more secure code or promises less. In a world where nonexhaustive is default, hard-to-track bugs will be introduced frequently into many Swift developer's code.<span class="Apple-converted-space"> </span><br class=""><ul class=""><li class="">Evolving contracts - The change you suggest leaves it up to the user to remember to add new cases into their code if an enum ever does change in a framework, and their code relies on exhaustive pattern matching.<span class="Apple-converted-space"> </span></li></ul></div></div></blockquote><div class="">I think this is the right thing to do. Library vendors can still communicate changes with clients through deprecation notices. Ultimately it is up to the vendor to maintain compatibility for people switching against those older cases, and up to the clients to adopt any new behaviour that gets implemented.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><ul class=""><li class="">Unhandled case bugs - This will lead to inconsistencies and hard-to-track bugs, since it would require the user to then track down an unhandled case that they may not even be aware exists (forcing googling, searching through documentation, etc.).</li></ul>This is something that I certainly have experienced in the past working across teams programming in Obj-C, and Swift has so far completely eliminated this class of bugs! In a world where exhaustive remains default, nothing changes, fewer bugs.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I’m not sure that those issues are so difficult to track down. You’ll know that switch statements which fall-through to a default case are suspicious - but they already are today, too!. It’s not really any different to having allowing singular “if”s without a corresponding “else”. I could also see the debugging value in a “future” case label, but it’s not necessary IMO.</div><div class=""><br class=""></div><div class="">Although, I can kind of see your point:</div><div class=""><br class=""></div><div class="">If you’re talking about a private framework (e.g. the multi-module App scenario), then things are a little different for you because typically, you’ll ship new versions of the framework and App together. The framework can be as fragile as you like in that case - you can break all the ABI stability rules, because there will no apps importing the new version of the framework who were compiled against older versions of it. In many ways, those frameworks are really like static libraries (with extras, like resources).</div></div></div></blockquote><br class=""></div><div>Of course, you can’t actually use static libraries because on iOS, for example, you might have XPC services or other mini-applications which also want to use your model libraries. Static libraries would bloat your binary size.</div><div><br class=""></div><div>Is there some kind of middle-ground, perhaps? Like a fragile dynamic library, which makes no attempt to be resilient?</div><div><br class=""></div><div>- Karl</div><br class=""></body></html>