RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v5]

[Maurizio Cimadamore]

On Mon, 24 Apr 2023 09:05:56 GMT, Rémi Forax <forax at openjdk.org> wrote:

> > I believe the exhaustiveness algorithm needs rules for union types, both in javac and in the JLS:
> > ...
> > I would expect the above switch to be exhaustive, since it covers all possible components of the union type. In other words, the union type should act as a sealed hierarchy which permits Foo and Bar - and the two cases should be merged together (e.g. `case Foo` + `case Bar` should cover `Foo | Bar`). For the records, I get same error on JDK 20.
> 
> Precise exception type, here, `Foo | Bar` inside a catch is not an union, it's a way to merge catches when the body of catches are the same. In term of typing, `Foo | Bar` behave as the lub of Foo and Bar, apart in a throw.
> 
> So the switch is not exhaustive here because `lub(Foo, Bar) = Exception`.
> 
> We may add a special case in JLS for supporting precise exception type in switch given that this issue have been reported several times, but this is not something that should be fixed by this PR.

I see the dance in 14.20 between:

"
 A catch clause whose exception parameter is denoted as a union of types is called a multi-catch clause. 
 "

And

"The declared type of an exception parameter that denotes its type as a union with alternatives D1 | D2 | ... | Dn is lub(D1, D2, ..., Dn). "

(Which is required to make membership (and other properties) work)

The reason I'm bringing this up in the context of the new exhaustiveness analysis is that this might add more ways to unify a pair of types in the exhaustiveness algorithm, hence leading to a more complex implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13074#issuecomment-1520030010