On Mon, 24 Apr 2023 12:05:35 GMT, Maurizio Cimadamore <mcimadam...@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.

In this case, as long as the union type could only be present at the top level 
(as opposed to e.g. a type of a record component), we could simply require all 
components to be covered for union types for exhaustiveness in `checkCovered`, 
no? We could do something different, if we had a good reason, but enhancing 
`checkCovered` should be enough, and shouldn't be too difficult (as long as the 
spec would say so). Do I miss something?

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

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

Reply via email to