<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 2, 2018 at 12:47 AM, Chris Lattner via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>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></div></blockquote><div><br></div><div>Yes, absolutely. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>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></div></blockquote><div><br></div><div>I agree 100%</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>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.<br></div></div></div></blockquote><div><br></div><div>I take slight exception to the word “only” here: the proposal as written does not offer compile-time feedback to inform client programmers that external enums on which they “switch” have new cases, because they are required to include a “default” clause.</div><div><br></div><div>Yes, those client programmers need to handle unknown cases, but they *also* deserve the compiler’s assistance in identifying when such cases have been added. I don’t know if a “future” keyword is the best approach, but we ought to include some way to warn (not error) when compiling a switch statement that the author intends to be exhaustive-over-all-known-cases while also handling unknown ones.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>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><br></div><div>-Chris</div></div></div></blockquote><div><br></div><div>If we can make that work, this proposal will be much more palatable.</div><div><br></div><div>Nevin</div></div></div></div>