> 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
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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
