[swift-evolution] Enums and Source Compatibility - defaults

[Jordan Rose]

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

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170810/a29f2765/attachment.html>