Switch labels (null again), some tweaking

[Brian Goetz]

Without diving into the translation details prematurely, I just want to 
note that we *do* want the compiler to "totalize" things for us, 
because, DA.  Suppose we have A permits B, C:

     int x ;
     switch (a) {
         case B(int foo): x = foo; break;
         case C(int bar): x = bar; break;
     }
     // HERE

There is some remainder -- null, D -- but we don't want that remainder 
to leak past the switch; when we get to HERE, we'd like x to be DA, and 
a to have matched one of the patterns.  So the compiler has to insert 
_something_ to handle the remaining cases, even if it is only:

     default: throw new TotalityException("blah blah");

But, the details of code generation are not what M is asking about now 
-- he's asking "if I were the user, could I write a truly covering 
switch?"  And the answer is yes, but the shape of the remainder is 
"spiny" and can get complicated quickly.

> Not necessarily.
>
> First, let's acknowledge that you are moving the discussion from the basic semantics to talk about the translation strategy which touch more the binary compatibility,
> aka, what is the semantics when the view of the world at compile time and at runtime are disagreeing.
>
> There are at least two reasons to let javac emits such cases,
> first like with null as remainder, you have to add a lot of cases once you have sub-patterns, so it will bloat the bytecode,
> then if we insert such cases, it means that we also have a code that throw a specific exception bolt into the bytecode which means that we can not change the binary compatibility story later.
>
> The jobs to implement the binary compatibility semantics is the job of the runtime not the compiler, like with lambdas, where the LambdaMetaFactory does some runtime checks before generating + linking the lambda proxy,
> I expect a SwitchMetafactory to do the same job. This is more flexible and allows the runtime to be updated when the VM change by example, the lambdaMetafactory code was changed with the introduction of hidden classes.
>
> Now, the big question is what binary compatibility semantics we want ?
>
> We can by example throw a subclass of LinkageError upfront during the linking when we detect that the sealed type as more subclasses that the one accessible at compile time, but it means that adding a new subclass to a sealed type is not a binary compatible change anymore. We can delay the detection the an incompatible class until we see one at runtime, so adding a new subclass is a compatible change but calling a switch with an instance of such subclass is not.
>
> There is also the question about the order of the cases, should the order of the cases be validated at runtime or not, by example, if we have B < A at compile time but A < B at runtime with a switch that like case B first and case A second.
>
>> Maurizio
> Rémi