I lean +1, but this answer on its own seems incomplete. Exhaustiveness is an important property, and it’s not clear what happens here now when you fall through a “complete” case tree without matching a pattern, and in that sense this plan solves a problem. But it also would hinder a “future-you” from going back and dealing with the ramifications of swapping a dependency for a newer version, in that with a default now covering the rest of the cases the compiler is unable to tell you which cases you are actually missing post-upgrade.
Library Evolution <https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst> includes what I think is the more complete response here: An @closed attribute for enums where a switch is guaranteed to be exhaustive. (Though, after the open discussion, I wonder if that keyword can’t be reused in some way to provide the inverse restriction instead). > On Feb 7, 2017, at 10:12 AM, 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 > <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
