I can assure you that I most definitely do not want an API developer adding to an exposed enum without me -the user- noticing it.
That would imo be a recipe for disaster. Regards, Rien. > On 7 Feb 2017, at 19:58, Tanner Nelson <tan...@qutheory.io> wrote: > > The point of the warning is to inform you that the author of the library you > depend on could cause your could not to compile by simply adding a case to > that enum. > > This is something you should be happy to avoid as someone writing a library > you want other people to depend on or as someone writing an application that > you don't want to find failing to compile in a few weeks or months. > > Sent from my iPhone > >> On Feb 7, 2017, at 19:49, Rien <r...@balancingrock.nl> wrote: >> >> If you don’t want the default case, and if you like a warning free >> compilation, you need a way to suppress the warning. >> >> 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 19:42, Tanner Nelson <tan...@qutheory.io> wrote: >>> >>> 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
