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.

Reply via email to