That's awesome. It looks like `(planned) Open and closed enums` is exactly what 
I'm looking for. 

Would it help if I created a concrete proposal for that or is it something the 
Swift team already has brewing?

Sent from my iPhone

> On Feb 7, 2017, at 22:01, Michael Ilseman <[email protected]> wrote:
> 
> BTW, this will likely be part of the eventual design of “open”/resilient 
> enums ala 
> https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums. 
> There, the goal is to reduce both ABI and source breakage caused by this sort 
> of thing. It seems like for your purposes, you’re less inclined to care about 
> ABI breakage than source breakage, though that may change in the future.
> 
> 
> 
>> On Feb 7, 2017, at 7:12 AM, Tanner Nelson via swift-evolution 
>> <[email protected]> wrote:
>> 
>> Hello Swift Evolution,
>> 
>> I'd like to propose that a warning be emitted when default cases are omitted 
>> for enums from other modules. 
>> 
>> What this would look like:
>> 
>> OtherModule:
>> ```
>> public enum SomeEnum {
>>     case one
>>     case two
>> }
>> 
>> public let global: SomeEnum = .one
>> ```
>> 
>> executable:
>> ```
>> import OtherModule
>> 
>> switch OtherModule.global {
>>     case .one: break
>>     case .two: break
>>     ^~~~~ ⚠︎ Warning: Default case recommended for imported enums. Fix-it: 
>> Add `default: break`
>> }
>> ```
>> 
>> Why:
>> 
>> Allowing the omission of a default case in an exhaustive switch makes the 
>> addition of a new case to the enum a breaking change. 
>> In other words, if you're exhaustively switching on an enum from an imported 
>> library, the imported library can break your code by adding a new case to 
>> that enum (which the library authors may erroneously view as an 
>> additive/minor-bump change).
>> 
>> Background:
>> 
>> As a maintainer of a Swift framework, public enums have been a pain point in 
>> maintaining semver. They've made it difficult to implement additive features 
>> and have necessitated the avoidance of enums in our future public API plans.
>> 
>> Related Twitter thread: 
>> https://twitter.com/tanner0101/status/796860273760104454
>> 
>> Looking forward to hearing your thoughts.
>> 
>> Best,
>> Tanner
>> 
>> Tanner Nelson
>> Vapor 
>> +1 (435) 773-2831
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to