> On Jan 17, 2018, at 14:42, Jordan Rose <jordan_r...@apple.com> wrote: > > > >> On Jan 17, 2018, at 14:41, Chris Lattner <clatt...@nondot.org >> <mailto:clatt...@nondot.org>> wrote: >> >>> On Jan 16, 2018, at 10:24 AM, Jordan Rose <jordan_r...@apple.com >>> <mailto:jordan_r...@apple.com>> wrote: >>>>> On Jan 12, 2018, at 3:08 PM, Jordan Rose <jordan_r...@apple.com >>>>> <mailto: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. >> >> 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. Jordan > But this is all implementation detail; it’s not interesting to discuss that. > > Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
