<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I also realize that this may be an impractical approach to solving this problem, because it would require teaching the analyzer about built products, with knowledge of what’s going to be copied, etc etc.<div class=""><br class=""></div><div class="">So, the alternative view to this would be:</div><div class=""><br class=""></div><div class="">- any enum that <i class="">you are compiling</i> is exhaustive</div><div class="">- everything else is non-exhaustive</div><div class=""><br class=""></div><div class="">Dave<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 28, 2017, at 4:18 PM, Dave DeLong via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I don’t think this use-case should be overlooked, <i class="">especially</i> as we approach the stable ABI.<div class=""><br class=""></div><div class="">If a library can change out from underneath you (because you’re not embedding it yourself) then it is inherently unsafe to assume that any enum in that library is exhaustive. The developer may think that it is for version 1, but the development of version 2 may reveal cases that were not originally considered. Apple, which has just about as much experience as anyone in the world with shipping frameworks, has a strong commitment to binary compatibility, but even they get it wrong sometimes.</div><div class=""><br class=""></div><div class="">IMO, the proper way to deal with “exhaustive” enums vs not is:</div><div class=""><br class=""></div><div class="">- any enum in any framework <i class="">you ship</i> is exhaustive. (Rationale: since you’re embedding it with your product, you have explicit control over handling all its cases)</div><div class=""><br class=""></div><div class="">- any enum in any framework <i class="">you link</i> is non-exhaustive. (Rationale: since the framework is not part of your product, it could change without you knowing, which means you must handle unexpected values via a default case)</div><div class=""><br class=""></div><div class="">Dave<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 21, 2017, at 12:48 PM, 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=""><br class=""><blockquote type="cite" class="">On Sep 20, 2017, at 16:15, Dave DeLong <<a href="mailto:swift@davedelong.com" class="">swift@davedelong.com</a>> wrote:<br class=""><br class="">Hi Jordan,<br class=""><br class="">One thing I’m still not clear on exhaustive vs non-exhaustive…<br class=""><br class="">What will stop a developer from releasing an exhaustive enum in version 1 of their library, and then adding a new case in version 2?<br class=""><br class="">With ABI stability and libraries getting updated independently of apps, this can be a major problem.<br class=""></blockquote><br class="">We have some ideas to deal with this, though nothing promised yet:<br class=""><br class="">- A checker that can compare APIs across library versions, using swiftmodule files or similar.<br class="">- Encoding the layout of a type in a symbol name. We could have clients link against this symbol so that they’d fail to launch if it changes, or just check the list of exported symbols to make sure it didn’t change.<br class=""><br class="">The feature’s useful even if we have to do it by hand for now, but it’s a good question to ask. I’ll mention this in the proposal under “Future directions”.<br class=""><br class="">Jordan</div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>