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 <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>> <[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 > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
