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


Reply via email to