Re: [swift-evolution] Enums and Source Compatibility - defaults

> 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, >

Re: [swift-evolution] Enums and Source Compatibility - defaults

Yes, I see your point, and that’s something I didn’t consider. If we allowed extending enums, this would then clearly indicate that “final” means something in the present as well - you cannot add cases. This opens up the can of worms of extending enums, but I think it’s a fair point if we ever

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On Aug 10, 2017, at 13:00, David Hart wrote: > > > > On 10 Aug 2017, at 19:19, Jordan Rose > wrote: > >> >> >>> On Aug 9, 2017, at 22:46, David Hart >> > wrote: >>>

Re: [swift-evolution] Enums and Source Compatibility - defaults

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

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On 10 Aug 2017, at 19:19, Jordan Rose wrote: > > > >>> On Aug 9, 2017, at 22:46, David Hart wrote: >>> >>> >>> On 10 Aug 2017, at 02:42, Jordan Rose wrote: >>> >>> :-) As you've all noted, there are some conflicting

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On Aug 9, 2017, at 22:46, David Hart wrote: > > >> On 10 Aug 2017, at 02:42, Jordan Rose > > wrote: >> >> :-) As you've all noted, there are some conflicting concerns for the default: >> >> - Source compatibility:

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On 10 Aug 2017, at 02:42, Jordan Rose wrote: > > :-) As you've all noted, there are some conflicting concerns for the default: > > - Source compatibility: the existing behavior for an unannotated enum is > "closed". > - Intuition: if you show someone an enum without

Re: [swift-evolution] Enums and Source Compatibility - defaults

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

Re: [swift-evolution] Enums and Source Compatibility - defaults

On Wed, Aug 9, 2017, at 08:42 PM, Jordan Rose via swift-evolution wrote:> - Consistency: switches on an enum in the same module can always be > exhaustive, so having it be different across modules is a bit > annoying. (But 'public' already acts like this.) >From someone frequently working on

Re: [swift-evolution] Enums and Source Compatibility - defaults

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

Re: [swift-evolution] Enums and Source Compatibility - defaults

:-) As you've all noted, there are some conflicting concerns for the default: - Source compatibility: the existing behavior for an unannotated enum is "closed". - Intuition: if you show someone an enum without an explicit annotation, they'll probably expect they can switch over it. (I'm going