[swift-evolution] Questions about non-exhaustive enums
jordan_rose at apple.com
Mon Jan 8 16:01:47 CST 2018
Good questions. The answer at a high level is "you break binary and source compatibility", and if you care about binary compatibility everything will fall to pieces (read: crashes, possibly undefined behavior). So our only goal on the binary compatibility is to make the "falling to pieces" as deterministic as possible, as described as a "Future direction"; we want library authors to not do this by mistake, and if they do we want apps to fail to launch rather than potentially corrupting user data.
For libraries that don't care about binary compatibility, breaking source compatibility is an option, if not one to be taken lightly. So:
- Adding a case to a frozen enum will result in errors in all switch statements without catch-all cases ('default' or '_' patterns), with the diagnostic saying that there is now an unhandled pattern. This is essentially the behavior of enums in Swift 4.
- Changing an enum from frozen to non-frozen will result in errors in all switch statements without catch-all cases, with the diagnostic saying that a switch over a non-frozen enum must include a catch-all pattern or `unknown case`. This is the diagnostic people will see when migrating from Swift 4 to Swift 5, so it has to be good anyway.
I'll add this to the proposal. Thanks, Nacho!
> On Jan 5, 2018, at 10:54, Ignacio Soto via swift-evolution <swift-evolution at swift.org> wrote:
> I love the revision to the proposal <https://github.com/apple/swift-evolution/pull/777>, but I have a couple of remaining questions that don't seem to be addressed in the doc and I'm curious about:
> What happens if a library maintainer adds a new case to a @frozen enum?
> What happens if a library maintainer changes an enum from @frozen to non-frozen?
> Ignacio Soto
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution