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

[Christopher Kornher]

-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