> On Jan 4, 2018, at 11:53 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > > On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez <ch...@masters3d.com > <mailto:ch...@masters3d.com>> wrote: > > > On Jan 4, 2018, at 10:49 AM, Jordan Rose <jordan_r...@apple.com > <mailto:jordan_r...@apple.com>> wrote: > >> 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 _`.) > > Can case _ be mixed with unknown case? How can we match all compile time > known cases but exclude future cases? > > What’s your use case for that? That eliminates the possibility of “unknown > case” giving you compile-time warnings for subsequently added cases, which > was the entire purpose of adding the syntax in the first place.
I was thinking of a generalized `unknown case` pattern but that is out of scope for this proposal. <https://github.com/apple/swift-evolution/pull/777/files#diff-a68dc745ee86d09566b232b6954c5158R321> switch excuse { case .eatenByPet : //… unknown case: // … case _: // … } > > Should there be something like `case *` that would capture all currently > known cases during compile time? case * and case _ would be the same in > exhaustive enums. This is why I was suggesting another pattern that only captures known cases at compile time: switch excuse { case .eatenByPet : //… case * : // All cases captured at compile time. // … unknown 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 >>> <mailto: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
