[Proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md>]
Whew! Thanks for your feedback, everyone. On the lighter side of
feedback—naming things—it seems that most people seem to like '@frozen', and
that does in fact have the connotations we want it to have. I like it too.
More seriously, this discussion has convinced me that it's worth including what
the proposal discusses as a 'future' case. The key point that swayed me is that
this can produce a warning when the switch is missing a case rather than an
error, which both provides the necessary compiler feedback to update your code
and allows your dependencies to continue compiling when you update to a newer
SDK. I know people on both sides won't be 100% satisfied with this, but does it
seem like a reasonable compromise?
The next question is how to spell it. I'm leaning towards `unexpected case:`,
which (a) is backwards-compatible, and (b) also handles "private cases", either
the fake kind that you can do in C (as described in the proposal), or some real
feature we might add to Swift some day. `unknown case:` isn't bad either.
I too would like to just do `unknown:` or `unexpected:` but that's technically
a source-breaking change:
switch foo {
case bar:
unknown:
while baz() {
while garply() {
if quux() {
break unknown
}
}
}
}
Another downside of the `unexpected case:` spelling is that it doesn't work as
part of a larger pattern. I don't have a good answer for that one, but perhaps
it's acceptable for now.
I'll write up a revision of the proposal soon and make sure the core team gets
my recommendation when they discuss the results of the review.
---
I'll respond to a few of the more intricate discussions tomorrow, including the
syntax of putting a new declaration inside the enum rather than outside. Thank
you again, everyone, and happy new year!
Jordan
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
