The main takeaways:
* case Number _ can fall out to other patterns since it doesn't introduce
any bindings (adjustment in the spec draft is needed)
* case Number _ dominates case String _, Integer _ (adjustment is not
needed in current draft, but I will double check before I circulate the revised
version).
Thanks for all the comments!
Thought experiment: what if we had union type patterns? Then the case label
`case String _, Integer _` would be like matching the the union type pattern
`(String|Integer) _`:
case Number n: ...
case (String|Integer) _: ...
Would javac then complain that `String|Integer` could be simplified to just
`String` on the bsais of flow analysis? (IntelliJ would, of course.)
I initially thought as Tagir did, but then Gavin turned me around and reminded
me that it was not dead code, but unreachable statements that we try to avoid.
So now I am torn...
Would union type patterns imply the existence of union types? If yes, then, the
second case could even exist with a binding, correct? In your example the LUB
is Object so even the case (String|Integer) x : x.getClass() can work. The
difficult scenario would arise with the case (Customer|Human) x : x.getName();
If the first case in your example did not introduce a binding, would both case
be equal with Number | (String | Integer)? Union types a la Ceylon support this
(http://web.mit.edu/ceylon_v1.3.3/ceylon-1.3.3/doc/en/spec/html_single/#uniontypes).
On the other hand in Ceylon, the switch needs to be exhaustive and​ all cases
need to be disjoint. So this switch would be invalid. hm..
________________________________
From: Maurizio Cimadamore <[email protected]>
Sent: 23 February 2023 20:27
To: Brian Goetz <[email protected]>; Angelos Bimpoudis
<[email protected]>; amber-spec-experts
<[email protected]>
Subject: Re: Draft JLS Spec about unnamed patterns and variables
On 23/02/2023 18:46, Brian Goetz wrote:
but we really wanted the case merging.
Gotcha.
I just wanted to point out that there are two questions here (one about
fall-through and one about domination), and when reading the emails it was not
obvious to me that a change in how fall-through was defined was being proposed.
If merging unrelated type tests is a goal, I think there should be an example
for it in the JEP under "Motivation".
Maurizio
