[swift-evolution] Warning when omitting default case for imported enums

[Tanner Nelson]

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 <milseman at apple.com> 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 <swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170207/a72e2208/attachment.html>