[swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Jordan Rose]

> On Jan 4, 2018, at 11:45, Cheyo Jimenez <cheyo at masters3d.com> wrote:
> 
> 
> 
> On Jan 4, 2018, at 10:49 AM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at 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 thought about this, but I couldn’t think of a use case for it. You won’t get any exhaustivity checks, and if you recompile the app you silently get different behavior. That didn’t seem like a good idea to me.

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180104/7e2814a3/attachment.html>