Expression switch exception naming

[Brian Goetz]

> So I buy Brian's argument that this is not an Error but a RE.
> I bought it on a hunch, and the above reasoning seems to
> bear it out under morescrutiny.
>

After further discussion, the Error-vs-Exception debate here was really 
a proxy for a more important question, which is: are we justified in 
assuming that enums are effectively sealed, and using that in the 
semantics of switch.  So far none of the answers are all that great.

Clearly, we're not adding any more booleans, so a switch that covers 
true and false is exhaustive.  We're pretty comfortable with the idea 
that boolean is sealed.  (You could make the same argument for byte.)

For an explicitly sealed type, I buy it's an ICCE when an unexpected 
subtype shows up.  The author said "these are the only three subtypes", 
so a fourth is definitely cause for worry that your configuration is 
borked.

Enums are in the middle.  We'd like to behave as if they're sealed, but 
they're not, and for some enums, they really are intended to be not 
sealed.  (The "language version" enum in javax.lang.model or the API 
version enum in ASM are obvious examples.)

Here's an idea that was pretty unpopular when I first brought it up, but 
now that people see the problem more, might offer more light on the 
problem, which is, to consider boundaries.

If I have a class:

     class C {
         enum E { A,B; }

        ... switch (e) ...
    }

its pretty clear that a switch that covers A and B is exhaustive; I 
can't add cases without recompiling C.  Here, the user would surely want 
us to infer sealed-ness for E.

If I have two classes in the same _package_ ... can I make the same 
assumption?  I think so.  Packages are intended to be compiled as a 
unit.  In fact, _modules_ are intended to be compiled as a unit. The 
assumption of sealed-ness for enums used within a package or module is 
pretty reasonable.

Its when we get to uses across module boundaries that inferring 
sealed-ness in the absence of an explicit annotation to that effect is 
questionable.

Now, no one is comfortable with the idea of using package or module 
boundaries here, but ultimately, the problem is that the validity of the 
assumption of sealed-ness is dependent on boundaries.