That is in fact what the proposal states: > Currently, adding a new case to an enum is a source-breaking change, which is > very inconvenient for library authors. This proposal aims to distinguish > between enums that are exhaustive (meaning they will never get any new cases) > and those that are non-exhaustive, and to ensure that clients handle any > future cases when dealing with the latter. This change only affects clients > from outside the original module.
> When a client tries to switch over a nonexhaustive enum, they must include a > default case unless the enum is declared in the same module as the switch. Do you have any suggestions on how to make this clearer in the proposal? Jordan > On Sep 15, 2017, at 21:40, Jon Shier <j...@jonshier.com> wrote: > > In that case Jordan, can Swift not treat it like open? i.e. Internally > to a module, unmarked enums are still exhaustive by default, but when made > public and used beyond the module, it becomes non-exhaustive? I think this > has been discussed before and perhaps discarded as confusing, but it doesn’t > seem to be any more confusing than open being the default internally and > closed the default publicly. Otherwise you’re essentially forcing what is > likely the vast majority of enum usage to adopt a bit of boilerplate that > will only be used by the vast minority of libraries (almost entirely > libraries shipped by Apple). > > > Jon > >> On Sep 15, 2017, at 8:07 PM, 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
