<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 12:54, Charlie Monroe <<a href="mailto:charlie@charliemonroe.net" class="">charlie@charliemonroe.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">I think that the main confusion here stems from the word library as we are addressing something that can be divided further (and this is IMHO as many macOS/iOS devs see it):</div><div class=""><br class=""></div><div class="">- <b class="">libraries that come with the OS</b> - here, it absolutely makes sense to make the enums non-exhaustive as the apps are linked against these libraries and the user installs a binary that will load these at launch and they are not bundled with the app - the developer can't control future OS releases and he wants the app to run on a future OS release.</div><div class="">- <b class="">libraries that are bundled with the app</b> - be it PM, CocoaPods or something else - you typically update your dependencies once in a while and they change. And you want to be notified by the compiler about possible changes - extended enums, in this case. Because let's be honest - if your app has a dozen dependencies and you come to the app after a year of no development, Swift 5 came along during that period, you want to update these libraries to Swift-5-compatible versions. And no one has the time to go through all change logs - even if they were kept up-to-date and thorough, which I can't say that I've seen in many instances.</div><div class=""><br class=""></div>I know that this is a limited view from the perspective of an app developer and that potentially, e.g. on Linux, there may be libraries written in Swift that you may want to install via package managers and depend on them once the ABI is stable, but the choice to make them non-exhaustive by default is not in line with everything else in Swift - everything else is generally closed by default - public (-> final in other modules), no access modified (-> internal), ...<div class=""><br class=""></div><div class="">For me, it's a -1 as it is now. I'd prefer exhaustive-by-default, ObjC/C-import non-exhaustive by default (the way ObjC classes are open by default vs. public). When it comes to the switch statement, there definitely needs to be an option to make an exhaustive switch over all compile-time-known values with a warning shall a new one be added. Without that, the code will become incredibly prone to errors and hard to maintain.<br class=""></div></div></div></blockquote><div><br class=""></div><div>This does bring up another option, which is to differentiate Apple-provided libraries (and in general, libraries with binary compatibility concerns, i.e. libraries that may be different at run-time from what you compiled against) from bundled / built-from-source libraries. Slava and I have been very leery of this because it fragments the language into dialects, and has the potential to confuse people when they try to write code that behaves like an Apple framework, but I suppose it is an option.</div><div><br class=""></div><div>Jordan</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 9:35 PM, 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=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 20. Dec 2017, at 19:54, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 05:36, 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=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 19. Dec 2017, at 23:58, Ted Kremenek 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=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><p style="-webkit-print-color-adjust: exact; margin-right: 0px; margin-bottom: 15px; margin-left: 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); margin-top: 0px !important;" class="">The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through <strong style="-webkit-print-color-adjust: exact;" class="">January 3, 2018</strong>.</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">The proposal is available here:</p><blockquote style="-webkit-print-color-adjust: exact; margin: 15px 0px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); padding: 0px 15px; color: rgb(119, 119, 119); font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class=""><div style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md</a></div></blockquote></div></div></blockquote><div class="">+1, it needs to happen (and ASAP, since it _will_ introduce source-breaking changes one way or the other).</div><div class=""><br class=""></div><div class="">I think non-exhaustive is the correct default. However, does this not mean that, by default, enums will be boxed because the receiver doesn’t know their potential size?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">It's not always boxing, but yes, there will be more indirection if the <i class="">compiler</i> can't see the contents of the enum. (More on that below.)</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">That would mean that the best transition path for multi-module Apps would be to make your enums @exhaustive, rather than adding “default” statements (which is unfortunate, because I imagine when this change hits, the way you’ll notice will be complaints about missing “default” statements).</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yep, that's going to be the recommendation. The current minimal-for-review implementation does not do this but I'd like to figure out how to improve that; at the very least it might be a sensible thing to do in the migrator.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">I do have some thoughts about how we could ease the transition (for this and other resilience-related changes), but it’s best to leave that to a separate discussion.</div><div class=""><br class=""></div><div class="">The one thing I’m still not overly fond of is the name - I would like us to keep the set of resilience/optimisation related keywords to a minimum. “exhaustive” for enums feels an awful lot like “fixed_contents” for structs - couldn’t we come up with a single name which could be used for both? I don’t think anybody’s going to want to use “exhaustive” for structs.</div></div></div></div></blockquote><br class=""></div><div class="">The core team was very focused on this too, but I contend that "exhaustive" is not about optimization and really isn't even about "resilience" (i.e. the ability to evolve a library's API while preserving binary compatibility). It's a semantic feature of an enum, much like 'open' or 'final' is for classes, and it affects what a client can or can't do with an enum. For libaries compiled from source, it won't affect performance at all—the <i class="">compiler</i> still knows the full set of cases in the <i class="">current</i> version of the library even if the programmer is forced to consider future versions.</div><div class=""><br class=""></div><div class="">I'm working on the fixed-contents proposal now, though it won't be ready for a while, and the same thing applies there: for structs compiled from source, the compiler can still do all the same optimizations. It's only when the library has binary compatibility concerns that we need to use extra indirection, and then "fixed-contents" becomes important. (As currently designed, it doesn't affect what clients can do with the struct at all.) This means that I don't expect a "normal" package author to write "fixed-contents" at all (however it ends up being spelled), whereas "exhaustive" is a fairly normal thing to consider whenever you make an enum public.</div><div class=""><br class=""></div><div class="">I hope that convinces you that "fixed-contents" and "exhaustive" don't need to have the same name. I don't think anyone loves the <i class="">particular</i> name "exhaustive", but as you see in the "Alternatives considered" we didn't manage to come up with anything significantly better. If reviewers all prefer something else we'd consider changing it.</div><div class=""><br class=""></div><div class="">Thanks for responding!</div><div class="">Jordan</div><br class=""></div></div></blockquote><br class=""></div><div class="">When you say “libraries compiled from source”, what do you mean?</div><div class=""><br class=""></div><div class="">As for whether its a resilience feature: actually it is completely a resilience feature. The effects on switching are only side-effects; really what “exhaustive” or “nonexhaustive” are saying is literally that cases may be added later. Even if we added private cases, you wouldn’t need to mark those enums as specially exhaustive or not; that would be implied. It’s an accommodation for things which don’t exist yet, so really, it is all about resilience IMO.</div><div class=""><br class=""></div><div class="">Anyway, as I see it, library authors in general ought to be happy about this:</div><div class="">+ Their libraries become safer by default, so they can make changes in the future without having to worry about breakage</div><div class="">+ It doesn’t affect your code inside of a module, so it only affects types they already explicitly marked “public”</div><div class=""><br class=""></div><div class="">The only people who lose are multi-module App developers, because they are “library authors” who don’t need to care about evolution, and now need to add attributes to things they wouldn’t have to before, or suffer language and performance penalties. Their libraries become less reusable and not resilient-by-default.</div><div class=""><br class=""></div><div class="">For example, I have an App for which I wrote a cross-platform model framework in Swift. When I compile it as a framework inside my App, it is bundled there forever. However, I use the same code to build libraries for Linux, which I would like to ship in binary form to 3rd-parties. Am I supposed to litter my code with annotations to mark those types as final, just to make the App fast and convenient to code? What happens when I need to fix a bug and distribute an updated copy, this means the 3rd-parties need to recompile (which they won’t do…).</div><div class=""><br class=""></div><div class="">Typically, for such a problem, I would recommend using a static library instead. But we don’t have those, and anyway they’re not always the best thing these days. So that’s why I started a new thread about creating a “@static” import, so App developers can go back to all the conveniences they had before.</div><div class=""><br class=""></div><div class="">- Karl</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""></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></div></div></blockquote></div><br class=""></body></html>