Since I was just looking at the Default section, it wasn’t clear that the default was just for the external case. But mostly I just wasn’t paying close attention. Also, it’s not entirely clear whether nonexhaustive enums can be used within the same module, but again, I may just be missing something.
Jon > On Sep 18, 2017, at 1:09 PM, Jordan Rose <jordan_r...@apple.com> wrote: > > 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 >> <mailto: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 >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
