Hi Jordan, One thing I’m still not clear on exhaustive vs non-exhaustive…
What will stop a developer from releasing an exhaustive enum in version 1 of their library, and then adding a new case in version 2? With ABI stability and libraries getting updated independently of apps, this can be a major problem. Dave > On Sep 18, 2017, at 11:48 AM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > I don't think unit tests help much here. In the case where an 'exhaustive' > enum ought to be 'nonexhaustive', unit tests wouldn't help you catch the > issue until you tried adding a new case. And in both cases, a unit test would > only help if you tried to switch exhaustively over the enum, something you > may not think to write (depending on what the enum is, of course). > > In either direction, there's a potential error of omission, and if you've > "omitted" the annotation from your library code I wouldn't assume you'd > remember to check that specific thing in a unit test. > > Jordan > > >> On Sep 16, 2017, at 00:44, Goffredo Marocchi <pana...@gmail.com >> <mailto:pana...@gmail.com>> wrote: >> >> Sorry for being naive, but aside from open (and the decision not to make it >> the default which again hurts the users of the library), wouldn’t the >> playground library example be ok if the framework author had validated it >> with unit tests? >> >> Sent from my iPhone >> >> On 16 Sep 2017, at 01:07, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> Hi, Rex. I definitely agree that 'exhaustive' is the right model for a >>> multi-module app; indeed, there's no real reason for a single project to do >>> anything else. However, it is not always the right behavior for libraries >>> that actually get distributed, whether as source or as binary. In this case >>> we want to minimize the error of omission: in the app case, forgetting >>> "exhaustive" is an annoyance that you notice and fix once across your code >>> base, but in the library case forgetting the "default case" means putting >>> out a source-breaking release, and for libraries that have binary >>> compatibility constraints there's no recourse at all. >>> >>> While most of the proposal deals with the experience we've had with the >>> Apple SDKs (as written in Objective-C), we actually have run into this case >>> in Swift already. The Swift Playgrounds app comes with a framework, >>> PlaygroundSupport, that can be used from within a playground. It's >>> important that when they upgrade the app, existing playgrounds don't break, >>> since the end user may not have access to the entire code of the >>> playground. (Remember that playgrounds are often authored by one developer >>> or group, but then run and modified by someone else with a much lower skill >>> level!) That means that PlaygroundSupport can't currently vend any enums >>> that they expect playground authors to exhaustively switch over. >>> >>> (And to make it even more specific—and appealing—one of the enums they were >>> considering would be a representation of the Swift AST. This can obviously >>> change from release to release, but previous switch statements should stay >>> valid.) >>> >>> Now, this is an example we know about, so we could certainly make it >>> explicitly non-exhaustive. But in general we're in the same situation as >>> 'open': if we want to be friendly to library authors, we need to make the >>> default thing be the one that promises less, even if it means a bit of >>> extra work in the "I-actually-own-everything" case. >>> >>> Best, >>> Jordan >>> >>> >>>> On Sep 15, 2017, at 15:47, Rex Fenley <r...@remind101.com >>>> <mailto:r...@remind101.com>> wrote: >>>> >>>> Hey Jordan, >>>> >>>> Thank you for the time writing this up. I've been following along to the >>>> discussion somewhat closely and have kept silent because `exhaustive` was >>>> originally set to be the default for enums. However, that changed and so >>>> I'd like to voice my opinion, I frankly don't like this idea. >>>> >>>> At remind we use algebraic data types religiously for managing state and >>>> data and rely on exhaustive pattern matching to guarantee we're handling >>>> all states in our code. We're splitting out our code across modules and >>>> having this guarantee has been a joy to work with. >>>> >>>> The benefit of making nonexhaustive the default for Swift 5 across all >>>> multi-module code (besides C code) seems minimal to me. If a developer >>>> feels like they're unnecessarily managing enum cases, they can simply add >>>> a `default` case whenever they please. This is already the case and I'm >>>> curious if there's every been any complaints about this and what they >>>> would be. I'd prefer to be cautious and force exhaustive pattern matching >>>> in all possible cases and leave it up to the developer to choose not to. >>>> >>>> Ideally in my mind, these keywords won't be necessary. All Swift enums >>>> will remain as they are, exhaustively pattern matched by default. Enums >>>> from C code will be explicitly nonexhaustive in all cases. >>>> >>>> -- >>>> Rex Fenley | IOS DEVELOPER >>>> >>>> >>>> Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | >>>> FOLLOW US <https://twitter.com/remindhq> | LIKE US >>>> <https://www.facebook.com/remindhq> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <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
