> On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > This is a very nice revision. One bikeshedding thought: > > Since "unknown case" is presented as a special kind of "default", can't be > mixed with "default", and can't be used in case patterns, why not "default > unknown" (or "unknown default") instead of "unknown case"?
`case _ :` is already a special case of default. I’d rather have `case unknown :` `unknown case :` is weird because of the order of `case`. Another alternative is `case \unknown :` `\unknown` would also allow pattern matching. > > > On Wed, Jan 3, 2018 at 8:05 PM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: >>> On Jan 2, 2018, at 18:07, Jordan Rose <jordan_r...@apple.com> 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! >> >> I ended up doing these in the opposite order, writing up the new proposal >> first and not yet responding to the discussion that's further out. You can >> read my revisions at https://github.com/apple/swift-evolution/pull/777. >> >> In particular, I want to at least address: >> - Dave D and Drew C's points about versioned libraries / linking semantics >> of modules. >> - Jason M's point about migration >> and I'll do one more pass over the thread to see if there's anything else I >> didn't address directly. (That doesn't mean everyone who disagrees, just >> messages where I think there's more I can do to explain why the proposal is >> the way it is.) >> >> Jordan >> >> P.S. Enjoying the Disney references. Thanks, Nevin and Dave. :-) >> >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
