Dominance in pattern matching for switch: Spec and Javac inconsistency

[Brian Goetz]

> yes,
> apart that we can detect the case where both guards are identical.
>
> something we currently do not do BTW.
>

That we don't do that now is a deliberate choice.  Even this is stepping 
onto the slippery slope; the ability to reason about guards falls off a 
cliff pretty quickly, and I'm not sure that handling the "easy cases" is 
doing the user a favor, when it risks lulling them into a false sense of 
confidence.  (We see this all the time with type inference; the better 
type inference is, the more upset people get when it doesn't read their 
mind.)

We could "easily" handle this:

     case int i && i > 0:
     case int i && i <= 0;

(and some languages do.)  But even the short hop to

     case int i && (i %2) == 0:
     case int i && (i %2) == 1;

is harder.  IntelliJ does heroics with abstract interpretation to find 
these things, which is great for an IDE, but less appropriate for a 
language spec.  So the question is, if we're going to venture onto that 
field, where do we draw the line?  Even "you specified exactly the same 
guard", once you get beyond a purely lexical definition of "same", is 
going to have holes.

The danger of attempting something so inherently incomplete is that we 
will invariably get drawn into a stream of "you do it here, but not 
there, that's a bug", which leads either to resources invested in 
low-value extensions, or low-value arguments about why we're not going 
to take then 342nd step (because, you already took the previous 341!)

So for now, we've drawn the line at "we're not gonna try"; we can always 
try harder later, since all that will do is make some switches that were 
already total but we didn't know it, into "total and we know it."