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

[Tanner Nelson]

I don't understand the part about warning suppression. The warning would go away when you add the default case. 

Sent from my iPhone

> On Feb 7, 2017, at 16:25, Rien <Rien at Balancingrock.nl> wrote:
> 
> -1
> 
> Reason 1: the “negative” behaviour you describe is actually exactly what I want to happen.
> Reason 2: Introducing a warning would also necessitate a warning suppression in order to have your code compile without warnings. But when you suppress, the purpose of the warning is nul and void.
> 
> PS: I would suggest not to use an enum in cases where this is really annoying and replace the enums with constants.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>> On 07 Feb 2017, at 16:12, 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
>