<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>Le 7 févr. 2017 à 14:45, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">I lean +1, but this answer on its own seems incomplete. Exhaustiveness is an important property, and it’s not clear what happens here now when you fall through a “complete” case tree without matching a pattern, and in that sense this plan solves a problem. But it also would hinder a “future-you” from going back and dealing with the ramifications of swapping a dependency for a newer version, in that with a <span style="color: rgb(186, 45, 162); font-family: Menlo; font-size: 11px;" class="">default</span> now covering the rest of the cases the compiler is unable to tell you which cases you are actually missing post-upgrade.<div class=""><br class=""></div></div></blockquote><div><br></div><div>I have not read the ABI stability stuff, so not sure if adding a new case to an enum inside a library can be made backward compatible but that would be nice. Handling this unexpected new value in the currently compiled user code should be as important as telling the owner of the user code that he must handle a new case.</div><div><br></div>Would a new pseudo-default keyword (unexpected, undefined) help here? Such keyword would require the switch statement to be exhaustive so it doesn't act like 'default' for switch exhaustiveness status at compile time, but does act like 'default' at runtime.<div><br></div><div>switch data {</div><div> case .one: { print("one') }</div><div> case .two: { print("two") }</div><div> undefined: { print("unexpected value") }</div><div>}</div><div><br></div><div>Replacing the library with one providing .three, will cause this previously compile code to print "unexpected value", and would cause the code to fail to compile against this same new library.</div><div><br></div><div>Dany</div><div><div><br></div><div><br><blockquote type="cite"><div><div class=""><a href="https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst" class="">Library Evolution</a> includes what I think is the more complete response here: An <span style="color: rgb(186, 45, 162); font-family: Menlo; font-size: 11px;" class="">@closed</span> attribute for enums where a switch is guaranteed to be exhaustive. (Though, after the <font color="#ba2da2" face="Menlo" class=""><span style="font-size: 11px;" class="">open </span></font>discussion, I wonder if that keyword can’t be reused in some way to provide the inverse restriction instead).<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 7, 2017, at 10:12 AM, Tanner Nelson 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="">Hello Swift Evolution,<div class=""><br class=""></div><div class="">I'd like to propose that a warning be emitted when default cases are omitted for enums from other modules. </div><div class=""><br class=""></div><div class="">What this would look like:</div><div class=""><br class=""></div><div class="">OtherModule:</div><div class="">```</div><div class="">public enum SomeEnum {</div><div class=""> case one</div><div class=""> case two</div><div class="">}</div><div class=""><br class=""></div><div class="">public let global: SomeEnum = .one</div><div class="">```</div><div class=""><br class=""></div><div class="">executable:</div><div class="">```</div><div class="">import OtherModule</div><div class=""><br class=""></div><div class="">switch OtherModule.global {</div><div class=""> case .one: break</div><div class=""> case .two: break</div><div class=""> ^~~~~ ⚠︎ Warning: Default case recommended for imported enums. Fix-it: Add `default: break`</div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">Why:</div><div class=""><br class=""></div><div class="">Allowing the omission of a default case in an exhaustive switch makes the addition of a new case to the enum a breaking change. </div><div class="">In other words, if you're exhaustively switching on an enum from an imported library, the imported library can break your code by adding a new case to that enum (which the library authors may erroneously view as an additive/minor-bump change).</div><div class=""><br class=""></div><div class="">Background:</div><div class=""><br class=""></div><div class="">As a maintainer of a Swift framework, public enums have been a pain point in maintaining semver. They've made it difficult to implement additive features and have necessitated the avoidance of enums in our future public API plans.</div><div class=""><br class=""></div><div class="">Related Twitter thread: <a href="https://twitter.com/tanner0101/status/796860273760104454" class="">https://twitter.com/tanner0101/status/796860273760104454</a></div><div class=""><br class=""></div><div class="">Looking forward to hearing your thoughts.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Tanner</div><div class=""><br class=""></div><div class=""><div style="font-family:'sf ui text';font-size:12px" class=""><font color="#5f5f5f" class="">Tanner Nelson</font></div><div style="font-family:'sf ui text';font-size:12px" class=""><font color="#9dacd1" class="">Va</font><font color="#aeb2cf" class="">p</font><font color="#c8bacd" class="">o</font><font color="#d0becc" class="">r</font><font color="#9dacd1" class=""> </font></div><div style="font-family:'sf ui text';font-size:12px" class=""><font color="#676767" class="">+1 (435) 773-2831</font></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></body></html>