[swift-evolution] Handling unknown cases in enums [RE: SE-0192]
jordan_rose at apple.com
Wed Jan 17 18:19:40 CST 2018
> On Jan 17, 2018, at 14:42, Jordan Rose <jordan_rose at apple.com> wrote:
>> On Jan 17, 2018, at 14:41, Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
>>> On Jan 16, 2018, at 10:24 AM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>>>>> On Jan 12, 2018, at 3:08 PM, Jordan Rose <jordan_rose at apple.com <mailto: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.)
>>>> 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.
>> The parser has fairly general support for declmodifiers, and my proposal fits directly into that. The only extension is that ‘default’ isn’t a decl, and I don’t think we have a statement modifier yet. That said, we’ve always planned to have them when the need arose.
> ‘case’ isn’t a decl in switches either. Nor is it a statement, the way things are modeled today.
Bleah, sorry, I forgot that it is a statement at the moment. But I don't think it needs to be modeled as a statement attribute/modifier. A flag on CaseStmt is fine.
> But this is all implementation detail; it’s not interesting to discuss that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution