You'd still get the compiler helping you with new cases when working with enums within your module.
There's less use in having the compiler help you find new cases when they can only be added between major versions of a package. The benefit to cost ratio here is imbalanced. Enum cases are forever frozen from version x.0.0 of a package forward (until the next major bump). No other programming language I know of prevents adding enum cases in a minor release. This makes using enums in public API (which are incredibly useful) very difficult to do while following semver. Could you explain more what you mean by public vs open enums? Best, Tanner Sent from my iPhone > On Feb 7, 2017, at 16:21, Charlie Monroe <[email protected]> wrote: > > -1 > > Not having the default case allows you to rely on the compiler to handle new > options once they are added. Most of my apps consist nowadays from multiple > modules and this would be massively inconvenient. > > The possible future features may be non-breaking if we consider that we will > not allow enums to be extended by default, but would need to be marked > explicitely as extendable. Similar to public vs. open classes. > >> On Feb 7, 2017, at 4:12 PM, 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
