Expression switch exception naming

[Brian Goetz]

> 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.