<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jan 16, 2018, at 10:24 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">On Jan 12, 2018, at 3:08 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:<br class=""><br class="">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.)<br class=""></blockquote><br class="">Thanks!<br class=""><br class="">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.<br class=""></div></div></blockquote></div><br class=""><div class="">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 <i class="">AST,</i> but that's an implementation detail.</div></div></div></blockquote><div><br class=""></div><div>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.</div></div><br class=""><div class="">-Chris</div></body></html>