> On Jan 12, 2018, at 22:49, Chris Lattner <clatt...@nondot.org> wrote:
>> On Jan 12, 2018, at 3:08 PM, Jordan Rose <jordan_r...@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 

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 

(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.)

swift-evolution mailing list

Reply via email to