I have no objection against removing that warning. The warning seems unnecessary to me.
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 22:13, Tanner Nelson <tan...@qutheory.io> wrote: > > 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 <ckorn...@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@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 <tan...@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 <r...@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@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@swift.org >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
