> On Jan 4, 2018, at 10:49 AM, Jordan Rose <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? Should be something like `case *` that would capture all currently known cases during compile time? case * and case _ would be the same in exhaustive enums. > > 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> wrote: >>> >>> >>>> 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
