Updated draft spec. Includes a small number of fixes and a correct "rebase" on top of the JLS changes resulting from JEP 432 (Record Patterns (Second Preview)) and JEP 433 (Pattern Matching for switch (Fourth Preview)) that covers Maurizio's point.
https://cr.openjdk.org/~abimpoudis/unnamed/latest/ (please note that the based URL has been slightly changed ^^) Comments are always very much welcomed! Best, Angelos ________________________________ From: Angelos Bimpoudis <[email protected]> Sent: 24 February 2023 17:23 To: Maurizio Cimadamore <[email protected]>; Brian Goetz <[email protected]>; amber-spec-experts <[email protected]> Subject: Re: Draft JLS Spec about unnamed patterns and variables 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
