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
  z...@waldowski.me


_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to