> On Jan 17, 2018, at 14:41, Chris Lattner <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. 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
