On Tue, Jan 2, 2018 at 12:47 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > 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. >
Yes, absolutely. > 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. > I agree 100% > 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. > 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. 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. > 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… > > -Chris > If we can make that work, this proposal will be much more palatable. Nevin
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
