Updated patterns-in-switch doc

Brian Goetz brian.goetz at oracle.com
Sun Sep 13 13:47:26 UTC 2020

> The sentence "Guarded patterns should be ignored entirely for purposes of computing totality." implies that if two patterns that only differ from one having a where and the other have not it's not valif to have them both in a switch seems wrong for me.

I suspect you have drawn the wrong implication from this statement.

> By example, a switch like this is illegal
>   switch(foo) {
>      case Bar bar where bar.x == 0 -> ...
>      case Bar bar -> ...
>      ...
>   }

This switch is perfectly legal and in fact we expect this pattern to be extremely common; we catch the special Bars first, and then have a catch-all for the rest of the Bars.  

The statement “ignored for purposes of computing totality” means that the *first* `case Bar where…` does not play into the computation of whether  the set of patterns is total on the target of the switch.  But the second `case Bar` does, because it is not guarded.  

> I believe that what we want is to consider that a pattern with a where clause is considered as a "subtype" of the pattern without a where clause, whatever the where clause is exactly.

That is the intuition; `case P where e` only covers some subset of the elements matched by P.  We just can’t conclude anything about totality from a guarded pattern.

We are not going to try to claim that 

    case Foo f where f.x() == 3:
    case Foo f where f.x() != 3:

is total on Foo; this is a fool’s errand.  So the logical thing to do is say “all bets regarding totality are off” for a particular case with a guard.  

Because the pattern you write is expected to be common, there will often be an unguarded version of the same pattern coming soon anyway, and it can play its role in totality computation.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200913/961a511a/attachment.htm>

More information about the amber-spec-experts mailing list