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
