On Tue, Jan 2, 2018 at 9:07 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote:
> [Proposal: https://github.com/apple/swift-evolution/blob/ > master/proposals/0192-non-exhaustive-enums.md] > > Whew! Thanks for your feedback, everyone. On the lighter side of > feedback—naming things—it seems that most people seem to like '*@frozen*', > and that does in fact have the connotations we want it to have. I like it > too. > > More seriously, this discussion has convinced me that it's worth including > what the proposal discusses as a *'future' case*. The key point that > swayed me is that this can produce a *warning* when the switch is missing > a case rather than an *error,* which both provides the necessary compiler > feedback to update your code and allows your dependencies to continue > compiling when you update to a newer SDK. I know people on both sides won't > be 100% satisfied with this, but does it seem like a reasonable compromise? > > The next question is how to spell it. I'm leaning towards `unexpected > case:`, which (a) is backwards-compatible, and (b) also handles "private > cases", either the fake kind that you can do in C (as described in the > proposal), or some real feature we might add to Swift some day. `unknown > case:` isn't bad either. > > I too would like to just do `unknown:` or `unexpected:` but that's > technically a source-breaking change: > > switch foo { > case bar: > unknown: > while baz() { > while garply() { > if quux() { > break unknown > } > } > } > } > > > Another downside of the `unexpected case:` spelling is that it doesn't > work as part of a larger pattern. I don't have a good answer for that one, > but perhaps it's acceptable for now. > > I'll write up a revision of the proposal soon and make sure the core team > gets my recommendation when they discuss the results of the review. > > --- > > I'll respond to a few of the more intricate discussions tomorrow, > including the syntax of putting a new declaration inside the enum rather > than outside. Thank you again, everyone, and happy new year! > > Jordan > +1 to warning instead of error +1 to unknown/unexpected case +1 to “@frozen” or any other reasonable spelling, they are all fine by me. The one remaining problem to solve is making sure multi-module apps can leave out the unknown/unexpected case on enums from modules which are part of the app itself and thus cannot be updated independently of it. John McCall’s version-locking plan sounds promising, though we should explore the available options before finalizing a course. Perhaps we need a concept of submodules, or supermodules, or some other way to demarcate the boundaries of a resilience domain. Nevin
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution