<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 30, 2016, at 5:02 PM, Jordan Rose via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@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; 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 27, 2016, at 16:32, David Sweeris via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" 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;"><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Nov 26, 2016, at 5:25 PM, Robert Widmann via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> 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. The consensus seems to be that the only safe way to deal with this situation is to<span class="Apple-converted-space"> </span><i class="">always</i> cover a `switch` statement with a default, regardless of whether the totality checker thinks you’ve covered all cases. 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;"> 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;"> switch self {</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;"> case .exit(_):</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;"> return false</span></div><div class="" style="font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="font-variant-ligatures: no-common-ligatures;"> 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;"> 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;"> 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;"> <span class="Apple-converted-space"> </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;"> <span class="Apple-converted-space"> </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;"> return false</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;"> }</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. 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 class="" 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;">Has the “resilient enum” thing been finalized, or is this kind of code just a preventative measure?</div><div class="" 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;"><br class=""></div><div class="" 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;">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 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="">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<span class="Apple-converted-space"> </span><i class="">do</i> want to know when new cases are added, so you can go update your switch statements as the author of the client.</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="">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 <a href="http://jrose-apple.github.io/swift-library-evolution/#enums" class="">Library Evolution document</a> describes how we want enums to behave in a resilient library, but doesn't discuss non-resilient source packages.</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="">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 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="">Jordan</div><br class="" 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;"></div></blockquote><div><br class=""></div><div>Idle thought: this discussion makes me think we might want a tristate for the different behaviours inside and outside the resilience domain:</div><div><br class=""></div><div>* closed: inside and outside are exhaustive; always warn on dead defaults</div><div>* open: inside and outside are inexhaustive; never warn on dead defaults</div><div>* “default”: inside is exhaustive, outside is inexhaustive; warn inside, but not outside</div><div>(the hypothetical 4th state seems incoherent to me)</div><div><br class=""></div><div>Basically the default behaviour is that I know what my enum is and would like the safety benefits of exhaustive matching, but I don’t want the evolution hazard of letting others exhaustively match. However I may <i class="">also</i> want the ability to be able to make certain enums act in-exhaustive <i class="">even in my own code. </i>This may be too niche to care about, though. Certainly this mode can be added later in a backwards compatible way.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><span 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; float: none; display: inline !important;" class="">_______________________________________________</span><br 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=""><span 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; float: none; display: inline !important;" class="">swift-dev mailing list</span><br 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=""><a href="mailto:swift-dev@swift.org" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">swift-dev@swift.org</a><br 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=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a></div></blockquote></div><br class=""></body></html>