Draft JEP on pattern matching

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Sun Jun 4 21:13:50 UTC 2017

On 04/06/17 14:52, Mark Raynsford wrote:
> How would the following behave with guards?
>    switch (c) {
>      case Integer i && i >= 0: return 1;
>      case Integer i && i >= 1: return 2;
>      default: return 3;
>    }
> What happens if c == 2?
> What happens if the guards have side effects?
> For that matter:
>    switch (c) {
>      case Integer i: return 1;
>      case Number n: return 2;
>      case Object o: return 3;
>      default: return 4;
>    }
> What happens if c is an Integer? A Number? An Object? Is the default
> branch actually necessary if one of the branches specifies Object with
> no guards?
Hi Mark,
we are planning to extend flow analysis to reason about pattern 
reachability - we have informally been talking about a 'dominance' 
relation between patterns - e.g. 'Object o' dominates 'Integer i', etc. 
If a pattern occurs after another that dominates it, then it is a 
compile-time error, as the pattern is unreachable. This is the basic 
story, and seems to  be working well - in the absence of 
break/continue/guards. Obviously we need to extend this basic story to 
take into account abnormal completion (continue) - but that should be 
easy to do. E.g. a pattern dominates some other pattern only if it 
completes normally (no continue).

As for guards, if you imagine desugaring guards as follows:

case p && g: ...


case p:
     if (!g) continue;

Then it follows that in your example no pattern is unreachable. That 
said, this story is potentially incomplete - as it doesn't cover the 
fact that there could be different guards which evaluate to true with 
similar inputs - e.g.

case Integer i && (i >= 0 && i < 5): return 1;
case Integer i && (i < 5 && i >= 0: return 2;

Using my proposed solution, this would be ok for the static compiler, 
but obviously the two guards are the same thing, just written in 
different way. My sense is that we can't do much for this kind of things 
in flow analysis, as you can always come up with more convoluted example 
which would defeat whatever complex logic you put into the static checks.


More information about the amber-dev mailing list