-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