> On Aug 9, 2017, at 20:00, Zach Waldowski via swift-evolution
> <email@example.com> wrote:
> 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
> 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.
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.)
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.
swift-evolution mailing list