<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 Aug 9, 2017, at 20:00, Zach Waldowski 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="">
<title class=""></title>
<div class=""><div style="font-family:Arial;" class="">On Wed, Aug 9, 2017, at 08:49 PM, Jordan Rose via swift-evolution wrote:<br class=""></div>
<blockquote type="cite" class=""><div class="">Ah, I forgot to mention: per my response to Charlie, the vast majority of enums in ObjC Foundation (80-90%) seem to be "open". I should have put that in the "open" side of the list. I'm not convinced that "APIs are designed differently in Swift" to the extent where you'd actually expect most enums to be closed; rather, I suspect most Swift API designers haven't been thinking too hard about exhaustive switches, and certainly not about binary compatibility, which becomes relevant at least for Apple once Swift libraries become part of the SDK.<br class=""></div>
</blockquote><div style="font-family:Arial;" class=""><br class=""></div>
<div style="font-family:Arial;" class="">Let me expound a bit. I was erroneously including string enums in my supposition that APIs are designed differently, but overall I still stand behind it.<br class=""></div>
<div style="font-family:Arial;" class=""><br class=""></div>
<div style="font-family:Arial;" class="">Foundation is designed for paper over lots of different computing concepts and underlying libraries with similar-ish APIs — in a good way! From the eyes of an API consumer, configuring something like a formatter to behave how they want is basically a write-only proposition. This makes simple enum cases a great design choice for hiding swaths of different underlying implementations (ex: NSDateFormatterShortStyle having a different meaning per-locale.)<br class=""></div>
<div style="font-family:Arial;" class=""><div style="font-family:Arial;" class=""><br class=""></div>
</div>
<div style="font-family:Arial;" class="">Say we split up Foundation's enums roughly into categories. You have your policies (NSURLCacheStoragePolicy, NSDateFormatterStyle), states/answers (NSURLSessionTaskState, NSQualityOfService), and, well, lists (NSSearchPathDirectory, NSStringEncoding). Given those, I’d say protocols, generics, and zero-cost abstractions are frequently a better choice (but not always). For instance, IMHO a closed protocol better models commonly-used styles.<br class=""></div>
<div style="font-family:Arial;" class=""><br class=""></div>
<div style="font-family:Arial;" class="">I know you ask to only consider open/closed enums in isolation to make it most likely to succeed, but there’s the frequent complaint that Swift has many ways to accomplish the same thing; I think resilience will land best with the community if it has a few really solid throughlines with the rest of the language, open/closed I hope being among them.<br class=""></div>
</div></div></blockquote><br class=""></div><div>For what it's worth, the rest of "resilience" mostly doesn't have semantic effects at all. Enums are special because of the source-affecting aspects. (That'll certainly make it weird to talk about the rest of resilience; I suspect most of the group won't be interested.)</div><div><br class=""></div><div>Thanks for listing this out, Zach. I don't think I agree with the conclusion that enums should and will be used less in Swift, but I'm not the only one whose opinion matters on this.</div><br class=""><div class="">Jordan</div></body></html>