<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="">Thanks for your feedback! I think you're missing the "libraries in the OS" aspect of this: if there are Swift libraries in iOS, and Apple ships a software update, some enums <i class="">will</i> get new cases. That means you can <i class="">always</i> end up in a default case if you were switching over those enums, and that's why 'switch!' has a '!' in it.<div class=""><br class=""></div><div class="">I sympathize with the "exhaustiveness diagnostics must be preserved" idea, but it simply doesn't account for package-based development. If libraries are allowed to add new cases without breaking source stability, they <i class="">must not</i> introduce new errors into clients. An app author cares about that because they want to use the latest Apple SDKs right away, even before any of their third-party library dependencies have released an update.</div><div class=""><br class=""></div><div class="">I do actually expect a number of third-party libraries to both mark their enums as exhaustive <i class="">and</i> add new cases in major releases (the ones that are allowed to be source-breaking). It's also a source-compatible change to mark a public enum as "exhaustive" that wasn't before, so I also expect an early flurry of bug reports when people realize this is important in Swift 5. But I think people will get the hang of it.</div><div class=""><br class=""></div><div class="">To be clear, I'm open to ideas in this space. It's just that both of the ideas in "Alternatives Considered" feel incomplete to me, and unfortunately we <i class="">do</i> have to do something in the near term for both imported enums and for Apple APIs (the overlays).</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 01:44, Jérôme Duquennoy 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=""><div class="">Hi guys,<br class=""><br class="">I am part of the people mentioned in "Preserve exhaustiveness diagnostics for non-exhaustive enums" : I see the completeness check as a major feature of enums, that makes a difference between it and a list of constants in multiple cases.<br class="">So much that in the coding rules of the company I work for, the use of default case requires some specific justification at review time.<br class=""><br class="">I have a positive opinion on this evolution if it comes with a solution to preserve exhaustiveness diagnostics. Otherwise, I think it lowers the ease of maintenance of code using external libraries.<br class=""><br class="">One of the risk I fear is that libraries builders might just forget to add the @exhaustive keyword. So it might end up being a pretty common case to have to specify "I want this switch to be exhaustive", just to not loose on maintainability. This could lead to a situation similar to the "fileprivate", that ended up being used much more than expected.<br class=""><br class="">It is not exactly in the scope of that review, but in the two solution for enforcing exhaustiveness drafted in that proposal, I would rather avoid the second one (the switch!). It would contradict the fact that as of today, the use of the exclamation mark in swift is a pretty clear sign that you are disabling some compiler-provided security at your own risk, and that it might lead to runtime crash (force unwrap, force cast, ...).<br class="">Here, requesting a switch to be exhaustive is adding one more compiler check. It cannot lead to a runtime crash.<br class="">I will be happy to discuss it further in a future review.<br class=""><br class="">Jerome<br class="">_______________________________________________<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></div></blockquote></div><br class=""></div></body></html>