<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="">I think this is a good summary. <div class=""><br class=""></div><div class="">I agree that we need to handle unexpected cases from changes to a binary somehow. The main issue is that, when forcing developers to use ‘default’ to do it, it also brings along unwanted semantics that prevent warnings in the very common use case of a 3rd party library being updated. The proposal is close to what we want, but unacceptable in it’s current form IMHO.</div><div class=""><br class=""></div><div class="">I see two possible solutions to this:</div><div class=""><br class=""></div><div class="">1) A new ‘unexpected:’ construct in switches, which handle cases not known at compile time. This is my favorite option because I think it gives us the most freedom to evolve the language in the future. For example, if we end up adding subclassable enums in Swift 12 or something, we will already have a mechanism in place to deal with the issues that arise.</div><div class=""><br class=""><div class="">2) We version the annotation, and then require any additions to map themselves back an existing case for code which doesn’t know about the new case.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I also feel like framing the issue as being about exhaustiveness of enums is confusing. It really doesn’t have to be about exhaustiveness at all. I would much prefer an annotation like <b class="">@frozen</b> which can be used for structs as well. With @exhaustive you have to start talking about module boundaries, because all enums are already exhaustive within the module boundary. You may find people adding @exhaustive for the wrong reasons (i.e. they want their local enum to be exhaustive). Framing the issue as something where we promise not to change the API is a much easier mental model to explain to people.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 1, 2018, at 9:48 PM, Chris Lattner 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; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">I agree that we need a solution to the problem described. I also agree that non-exhaustive is most in keeping with the overall design of Swift at module boundaries. However, I believe this proposal should be modified before being accepted</div></div></div></blockquote><div class=""><br class=""></div><div class="">Thanks for writing this up - you’ve explained a common concern in an interesting way:</div><div class=""><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This is likely to be a relatively rare need mostly encountered by 3rd party libraries but it will happen. When it does happen it would be really unfortunate to be forced to use a `default` clause rather than something like a `future` clause which will produce an error when compiled against an SDK where the enum includes cases that are not covered. I can imagine cases where this catch-all case would need to do something <i class="">other than </i>abort the program so I do not like the `switch!` suggestion that has been discussed. The programmer should still be responsible for determining the behavior of unknown cases.</div></div></blockquote><div class="">..</div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">While library authors have a legitimate need to reserve the right to introduce new cases for some enums this need can be met without taking away a useful tool for generating static compiler errors when code does not align with intent (in this case, the intent being to cover all known cases). Switch statements working with these kinds of enums should be required to cover unknown cases but should be able to do so while still being statically checked with regards to known cases. </div></div></blockquote><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div></div></div></div><div class="">I think that this could be the crux of some major confusion, the root of which is the difference between source packages and binary packages that are updated outside your control (e.g. the OS, or a dynamic library that is updated independently of your app like a 3rd party plugin). Consider:</div><div class=""><br class=""></div><div class="">1) When dealing with independently updated binary packages, your code *has* to implement some behavior for unexpected cases if the enum is non-exhaustive. It isn’t acceptable to not handle that case, and it isn’t acceptable to abort because then your app will start crashing when a new OS comes out. You have to build some sort of fallback into your app.</div><div class=""><br class=""></div><div class="">2) When dealing with a source package that contributes to your app (e.g. through SwiftPM), *YOU* control when you update that package, and therefore it is entirely reasonable to exhaustively handle enums even if that package owner didn’t “intend” for them to be exhaustive. When *you* chose to update the package, you get the “unhandled case” error, and you have maximal “knowability” about the package’s behavior.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">It seems that your concern stems from the fact that the feature as proposed is aligned around module boundaries, and therefore overly punishes source packages like #2. I hope you agree that in case #1, that the feature as proposed is the right and only thing we can do: you really do have to handle unknown future cases somehow.</div><div class=""><br class=""></div><div class="">If I’m getting this right, then maybe there is a variant of the proposal that ties the error/warning behavior to whether or not a module is a source module vs a binary module. The problem with that right now is that we have no infrastructure in the language to know this…</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""></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></div></body></html>