> On Jan 4, 2018, at 11:45, Cheyo Jimenez <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? 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
