-1 I prefer to have enums enforce that all cases are met otherwise use a default value.
If an API changes and adds new cases I want to know about it so that I can do something about it! If we hide it then weird and mysterious bugs might creep up On Tue, Feb 7, 2017 at 4:22 PM Tanner Nelson via swift-evolution < swift-evolution@swift.org> wrote: > That's awesome. It looks like `(planned) Open and closed enums` is > exactly what I'm looking for. > > Would it help if I created a concrete proposal for that or is it something > the Swift team already has brewing? > > Sent from my iPhone > > On Feb 7, 2017, at 22:01, Michael Ilseman <milse...@apple.com> wrote: > > BTW, this will likely be part of the eventual design of “open”/resilient > enums ala > https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums. > There, the goal is to reduce both ABI and source breakage caused by this > sort of thing. It seems like for your purposes, you’re less inclined to > care about ABI breakage than source breakage, though that may change in the > future. > > > > On Feb 7, 2017, at 7:12 AM, 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
