<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I am sorry, but I have to disagree here. Having two separate proposals would make it highly more likely that one thing is done and the other one postponed and postponed until it seems no longer relevant in the grand scheme of things... first we lost labels in callbacks / stores functions (has there been at least some Core Team chat about this after last year?) and now we are losing compiler enforced exhaustive switching over enum... not only that, until we improve diagnostic and at least warn users we are now even behind Objective-C as compiler can enforce exhaustive switching and actually mandate no default case for enums through a compiler warning.<div><br><div id="AppleMailSignature">Sent from my iPhone</div><div><br>On 11 Jan 2018, at 04:31, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 10, 2018, at 10:10 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="Singleton" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><blockquote type="cite" class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline">- Matching known cases is a feature, not a limitation, to avoid existing code changing meaning when you recompile. I'll admit that's not the strongest motivation, though, since other things can change the meaning of existing code when you recompile already.</div></blockquote><div class=""><br class=""></div><div class="">I’m not sure I understand this. </div><div class=""><br class=""></div><div class="">The whole motivation for this feature is to notify people if they are not handling a “newly known” case. If they don’t care about this, they can just use default.</div></div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Notify, yes. Error, no. It's a design goal that adding a new case does not break source compatibility in addition to not breaking binary compatibility (because people don't like editing their dependencies) and therefore the behavior has to be defined when they recompile with no changes.</span></div><div class=""><br class=""></div></div></div></blockquote><br class=""></div><div>Ok, if that’s the desired design, then (IMO) the right way to spell it is “unknown default:” and it should have semantics basically aligned with the design you laid out in the revision of the proposal. If this is supposed to be an error, then it should be a pattern production.</div><div><br class=""></div><div>Do you have a sense for whether this is what people want? We really should have a review cycle evaluating exactly this sort of tradeoff.</div><div><br class=""></div><div>In any case, I’ve said this before off-list, but I find this whole discussion (of how to improve diagnostics for unknown cases) to be separable from the core issue required to get to ABI stability. It seems to me that we could split this (ongoing) design discussion off into a separate SE, allowing you to get on with the relatively uncontroversial and critical parts in SE-0192.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>