It's not clear to me what the utility of nominally always having an
exhaustiveness check would be if I end up having to include a "default"
everywhere anyway. If someone adds an enum constant (and I'm compiling
my code against their new code), I want to get compilation errors in
every switch that now needs to be updated. If I have to add a "default"
everywhere in the source, I won't get that (and will have to hope that
my test coverage is good enough to find all the switches that are now
incorrect).
OK, we have a terminology confusion over the term "exhaustiveness
checking." I meant that the compiler won't let you write an
inexhaustive switch expression (which, for almost all target types, will
require a default/total pattern), even though it will let you for switch
statements (in the absence of flow constraints to the contrary, such as
a blank local.)
My understanding to date has been that a "default" wasn't going to be
required for enum and sealed types, and that if I didn't provide one,
the compiler would synthesize one that raises an exception... Now
things seem to have shifted somewhat.
They haven't shifted; I was describing this option as a means of getting
at Kevin's distinction about classpath dependencies. Within a
maintenance domain, you basically never have to worry about your enums
and switches over those enums getting out of sync; across maintenance
domains, you do. So the question was, should we consider treating
cross-module "hope nothing changes between now and runtime" assumptions
more skeptically. It was a thought experiment, not a proposal, aimed at
closing the loop (since this thread has had an awful lot of
talking-past-each-other.)
I configure my IDE to refuse to allow me to use default on enum
switches, and to treat missing cases as a compilation error:
switch (e) {
case RED: ...
case YELLOW: ...
case GREEN: ...
}
throw new UnreachableCodeException();
We'd not do anything for switch statements. Exhaustiveness checking is
only for switch expressions in any case.
But, your point is taken; *not* having a default in a situation that
requires exhaustiveness acts as a type-check on that exhaustiveness, and
saying default will then cover up any sins. I get it.
