[swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose]

> On Jan 12, 2018, at 22:49, Chris Lattner <clattner at nondot.org> wrote:
> 
> 
>> On Jan 12, 2018, at 3:08 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> 
>> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's point very specifically: if the compiler emits an error, we should go with `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
> 
> Thanks!
> 
> Out of curiosity, why not “unknown default:”?  The “warning” behavior is a customization of default, so this seems like a more logical model.  It also fits into the existing Swift grammar, unlike “unknown case:” which requires adding a new special case production.

I'm not sure how this fits more into the existing grammar. Both of them require custom parsing with one token's worth of lookahead. You're right that they suggest different natural modelings in the AST, but that's an implementation detail.

To me, `unknown case` is more meaningful than `unknown default`: it matches cases (as in, enum elements declared with `case`) that the developer doesn't know about. "unknown default" is talking about two different things; the "default" part talks about the switch and the code that will be executed, while "unknown" is talking about the input. But this isn't something I feel too strongly about; it will go to review, people will express their opinions, and then you and the rest of the core team will pick one name or the other based on feedback.

(It's also shorter, which gives it 0.3 extra aesthetic points. But unlike attributes or modifiers, it's less common to put things on the same line as switch cases, so that matters a lot less.)

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180116/7591f984/attachment.html>