-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
