<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 Feb 7, 2017, at 7:54 PM, Tanner Nelson &lt;<a href="mailto:tanner@qutheory.io" class="">tanner@qutheory.io</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">You'd still get the compiler helping you with new cases when working with enums within your module.&nbsp;</div></div></div></blockquote><div><br class=""></div><div>That's my point. My projects usually consist of several modules, as I've noted and I don't need to extend the enum from the other module (and in 99% of the cases it wouldn't make sense).</div><div><br class=""></div><div>And you'd get no error in the other modules, which is terrible if your default label goes to fatalError and you need to catch all these cases at runtime.</div><div><br class=""></div><div>Example:</div><div><br class=""></div><div>My project consists of Core framework that is shared among all my projects, then the app has AppCore that uses the Core framework and is shared between macOS and iOS apps and then I have the actual app.</div><div><br class=""></div><div>I.e. 3 modules that make one app. No need to extend enums. None so far. With what you suggest, I define an enum in the Core framework, AppCore and the App modules need to add "default" clause to their switch statements, usually fatalError, since that's the only plausible thing to do.</div><div><br class=""></div><div>Adding another member to the enum (in Core) does not create errors/warnings in AppCore and App, so the new enum case is handled by fatalError, causing the app to crash at runtime.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class="">There's less use in having the compiler help you find new cases when they can only be added between major versions of a package. The benefit to cost ratio here is imbalanced. Enum cases are forever frozen from version x.0.0 of a package forward (until the next major bump). No other programming language I know of prevents adding enum cases in a minor release. This makes using enums in public API <span class="" style="background-color: rgba(255, 255, 255, 0);">&nbsp;(which are incredibly useful)&nbsp;</span>very difficult to do while following semver.&nbsp;</div></div></blockquote><div><br class=""></div><div>Not really. I have many in-house frameworks that can simply add enum values - since it's all within my projects, I don't need to worry about breaking 3rd party code.</div><br class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class="">Could you explain more what you mean by public vs open enums?</div></div></blockquote><div><br class=""></div><div>Now you have two ways to offer class API to another module:</div><div><br class=""></div><div>- declare it public - to the other module, it appears as "final".</div><div>- declare it open - in the other module, it can be subclassed and members declared as open can be overridden</div><div><br class=""></div><div>In the same sense, you would declare an enum "open" instead of "public" to allow new members to be declared.</div><br class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">Best,</div><div class="">Tanner</div><div class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On Feb 7, 2017, at 16:21, Charlie Monroe &lt;<a href="mailto:charlie@charliemonroe.net" class="">charlie@charliemonroe.net</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">-1<div class=""><br class=""></div><div class="">Not having the default case allows you to rely on the compiler to handle new options once they are added. Most of my apps consist nowadays from multiple modules and this would be massively inconvenient.</div><div class=""><br class=""></div><div class="">The possible future features may be non-breaking if we consider that we will not allow enums to be extended by default, but would need to be marked explicitely as extendable. Similar to public vs. open classes.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 7, 2017, at 4:12 PM, Tanner Nelson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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.&nbsp;</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="">&nbsp; &nbsp; case one</div><div class="">&nbsp; &nbsp; 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="">&nbsp; &nbsp; case .one: break</div><div class="">&nbsp; &nbsp; case .two: break</div><div class="">&nbsp; &nbsp; ^~~~~ ⚠︎ 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.&nbsp;</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:&nbsp;<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="">&nbsp;</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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div></blockquote></div><br class=""></body></html>