<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 Nov 27, 2016, at 16:32, David Sweeris via swift-dev &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt; 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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Nov 26, 2016, at 5:25 PM, Robert Widmann via swift-dev &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div dir="auto" class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div dir="auto" class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hello all,<div class=""><br class=""></div><div class="">I’ve seen and been a part of a number of conversations recently where talk of planning for “resilient enums”, or even just authors that ship frameworks that will eventually offer a binary option that export enum-based APIs. &nbsp;The consensus seems to be that the only safe way to deal with this situation is to<span class="Apple-converted-space">&nbsp;</span><i class="">always</i>&nbsp;cover a `switch` statement with a default, regardless of whether the totality checker thinks you’ve covered all cases. &nbsp;Currently, the compiler warns when this is the case, as in stdlib</div><div class=""><br class=""></div><div class=""><div class="" style="margin: 0px; font-size: 11px; line-height: normal;"><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">extension ProcessTerminationStatus {</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; var isSwiftTrap: Bool {</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; &nbsp; switch self {</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; &nbsp; case .exit(_):</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; &nbsp; &nbsp; return false</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; &nbsp; case .signal(let signal):</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; &nbsp; &nbsp; return CInt(signal) == SIGILL || CInt(signal) == SIGTRAP</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; &nbsp; default:</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal; color: rgb(0, 132, 0);"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; &nbsp; &nbsp;<span class="Apple-converted-space">&nbsp;</span></span><span class="" style="font-variant-ligatures: no-common-ligatures;">// This default case is needed for standard library builds where</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal; color: rgb(0, 132, 0);"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; &nbsp; &nbsp;<span class="Apple-converted-space">&nbsp;</span></span><span class="" style="font-variant-ligatures: no-common-ligatures;">// resilience is enabled</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; &nbsp; &nbsp; return false</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; &nbsp; }</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">&nbsp; }</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;">}</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;"><br class=""></span></div><div class="" style="margin: 0px; line-height: normal;">I think this warning doesn’t actually serve a purpose and I’d like to remove it, or at the very least curb it. &nbsp;Currently, I see three paths forward:</div><div class="" style="margin: 0px; line-height: normal;"><br class=""></div><div class="" style="margin: 0px; line-height: normal;">1) Do nothing.</div><div class="" style="margin: 0px; line-height: normal;">2) Completely remove the diagnostic</div><div class="" style="margin: 0px; line-height: normal;">3) Only emit the diagnostic when the case-tree is switching over enum(s) declared inside the current module.</div></div></div></div></div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Has the “resilient enum” thing been finalized, or is this kind of code just a preventative measure?</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Also, if “resilience” is a compiler flag, there's a fourth option: Disable the warning on builds that have “resilience” enabled.</div></div></blockquote><br class=""></div><div>This issue isn't really specific to resilience. If you depend on some third-party library through the Swift package manager, that library should be free to add new cases to enums in new releases without that being a source-breaking change. On the other hand, maybe you <i class="">do</i>&nbsp;want to know when new cases are added, so you can go update your switch statements as the author of the client.</div><div><br class=""></div><div>There hasn't been any formal proposal for open vs. closed enums yet. Today all Swift enums are treated as closed, while imported C enums are sometimes treated as closed (switch) and sometimes as open (init(rawValue:) always succeeding). The&nbsp;<a href="http://jrose-apple.github.io/swift-library-evolution/#enums" class="">Library Evolution document</a>&nbsp;describes how we want enums to behave in a resilient library, but doesn't discuss non-resilient source packages.</div><div><br class=""></div><div>I'd lean towards (3) as the right answer for now, but it would also be great to start the ball rolling on designing a "closed" annotation for enums that makes sense for both source and binary distribution.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>