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

[Tanner Nelson]

Adding a default case when you've exhaustively switched on the enum results in a warning currently. The default case is not really optional at that point if you want to compile without warnings. 

```
warning: default will never be executed default: break
```

Sent from my iPhone

> On Feb 7, 2017, at 20:13, Christopher Kornher <ckornher at me.com> wrote:
> 
> -1 This warning suggestion is of highly questionable value. Authors are free to add a default case or not, depending upon the nature of the enum and the logic to handle them. There is no “right” way to suggest, although for high-reliability code, default cases should usually be avoided in my opinion.
> 
> 
>> On Feb 7, 2017, at 11:49 AM, Rien via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> If you don’t want the default case, and if you like a warning free compilation, you need a way to suppress the warning.
>> 
>> 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 19:42, Tanner Nelson <tanner at qutheory.io> wrote:
>>> 
>>> 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
>>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>