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