On Wed, Aug 9, 2017, at 08:49 PM, Jordan Rose via swift-evolution wrote:> 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. 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. 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.) 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. 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. Sincerely, Zachary Waldowski [email protected]
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
