I'll admit I hadn't thought of using "unknown default" (or "default unknown"). I don't think that's terrible, but I mildly prefer `unknown case` because it builds on the "pun" that enum elements are also defined using 'case'. If anything hits this part of the switch, it really will be an "unknown case", i.e. a statically-unknown enum element.
To Cheyo's point, if this were to be a single token I'd probably spell it #unknown, like #available. Then we'd have `case #unknown:` and something that naturally expands to other pattern positions. I found that less aesthetically pleasing, though, and so a context-sensitive keyword seemed like the way to go. (For the record, though, I wouldn't describe `case _` as a special case of `default`. They do exactly the same thing, and `_` is a useful pattern in other contexts, so if anything the current `default` should be thought of as syntactic sugar for `case _`.) I'll add these points to the "Alternatives Considered" section in the PR later today. Jordan > On Jan 3, 2018, at 22:56, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > As has already been said, “case unknown” is source-breaking because it > conflicts with any real cases named “unknown”; “\unknown” looks like a key > path but isn’t, and I wonder if it would potentially conflict with existing > key paths. > > In any case, my point was not to bikeshed the “unknown” part, but to ask > whether any consideration had been made to have the feature presented as a > flavor of default instead of a flavor of case. > > On Wed, Jan 3, 2018 at 23:57 Cheyo Jimenez <ch...@masters3d.com > <mailto:ch...@masters3d.com>> wrote: > > > On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>> wrote: >>> On Jan 2, 2018, at 18:07, Jordan Rose <jordan_r...@apple.com >>> <mailto:jordan_r...@apple.com>> wrote: >>> >>> [Proposal: >>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md >>> >>> <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 >> <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 <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 <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
