> 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

Reply via email to