> On Nov 30, 2016, at 5:02 PM, Jordan Rose via swift-dev <swift-dev@swift.org> > wrote: > >> >> On Nov 27, 2016, at 16:32, David Sweeris via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >>> >>> On Nov 26, 2016, at 5:25 PM, Robert Widmann via swift-dev >>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>> >>> Hello all, >>> >>> I’ve seen and been a part of a number of conversations recently where talk >>> of planning for “resilient enums”, or even just authors that ship >>> frameworks that will eventually offer a binary option that export >>> enum-based APIs. The consensus seems to be that the only safe way to deal >>> with this situation is to always cover a `switch` statement with a default, >>> regardless of whether the totality checker thinks you’ve covered all cases. >>> Currently, the compiler warns when this is the case, as in stdlib >>> >>> extension ProcessTerminationStatus { >>> var isSwiftTrap: Bool { >>> switch self { >>> case .exit(_): >>> return false >>> case .signal(let signal): >>> return CInt(signal) == SIGILL || CInt(signal) == SIGTRAP >>> default: >>> // This default case is needed for standard library builds where >>> // resilience is enabled >>> return false >>> } >>> } >>> } >>> >>> I think this warning doesn’t actually serve a purpose and I’d like to >>> remove it, or at the very least curb it. Currently, I see three paths >>> forward: >>> >>> 1) Do nothing. >>> 2) Completely remove the diagnostic >>> 3) Only emit the diagnostic when the case-tree is switching over enum(s) >>> declared inside the current module. >> >> Has the “resilient enum” thing been finalized, or is this kind of code just >> a preventative measure? >> >> Also, if “resilience” is a compiler flag, there's a fourth option: Disable >> the warning on builds that have “resilience” enabled. > > This issue isn't really specific to resilience. If you depend on some > third-party library through the Swift package manager, that library should be > free to add new cases to enums in new releases without that being a > source-breaking change. On the other hand, maybe you do want to know when new > cases are added, so you can go update your switch statements as the author of > the client. > > There hasn't been any formal proposal for open vs. closed enums yet. Today > all Swift enums are treated as closed, while imported C enums are sometimes > treated as closed (switch) and sometimes as open (init(rawValue:) always > succeeding). The Library Evolution document > <http://jrose-apple.github.io/swift-library-evolution/#enums> describes how > we want enums to behave in a resilient library, but doesn't discuss > non-resilient source packages. > > I'd lean towards (3) as the right answer for now, but it would also be great > to start the ball rolling on designing a "closed" annotation for enums that > makes sense for both source and binary distribution. > > Jordan >
Idle thought: this discussion makes me think we might want a tristate for the different behaviours inside and outside the resilience domain: * closed: inside and outside are exhaustive; always warn on dead defaults * open: inside and outside are inexhaustive; never warn on dead defaults * “default”: inside is exhaustive, outside is inexhaustive; warn inside, but not outside (the hypothetical 4th state seems incoherent to me) Basically the default behaviour is that I know what my enum is and would like the safety benefits of exhaustive matching, but I don’t want the evolution hazard of letting others exhaustively match. However I may also want the ability to be able to make certain enums act in-exhaustive even in my own code. This may be too niche to care about, though. Certainly this mode can be added later in a backwards compatible way. > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org <mailto:swift-dev@swift.org> > https://lists.swift.org/mailman/listinfo/swift-dev > <https://lists.swift.org/mailman/listinfo/swift-dev>
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
