> On Aug 9, 2017, at 20:00, Zach Waldowski via swift-evolution 
> <swift-evolution@swift.org> 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 
> 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.

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

Reply via email to