Draft JLS Spec about unnamed patterns and variables

[Brian Goetz]

In 14.11.1, you say:

> *For a case label with case patterns, it is a compile-time error if 
> any of its case patterns declares one or more pattern variables.*

But don't you really mean "For a case label with _more than one_ case 
patterns, it is ..."?

I could see this being implicit in the "s" at the end of "case 
patterns", but this would be a pretty subtle distinction.

The following text has a typo: "more than case patterns" -> "more than 
ONE case pattern".

I see that you've switched horses on domination; now any "dead pattern" 
is an error.  I am fine with this (though Gavin did make a good argument 
for the alternative.)

In 14.11.1.2, we talk about resolution of patterns.  If any of the 
patterns resolves to an any pattern, then it will dominate the others.  
I believe this is already handled by the text about "if one dominates 
the others" so that case is already handled, good.

You commit here to strict left-to-right evaluation of patterns when 
there are multiple patterns on a case.  This is reasonable, but bear in 
mind that such L2R commitments do potentially interfere with folding 
optimizations if any of the patterns involve imperative code such as 
accessors or deconstructors.

`when (Boolean) null` -- yuck :)  Well spotted.

The text around any patterns and resolution in 14.30.1 seems like it 
could still be simplified a bit.







On 2/28/2023 11:21 AM, Angelos Bimpoudis wrote:
> 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 <angelos.bimpoudis at oracle.com>
> *Sent:* 24 February 2023 17:23
> *To:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>; Brian 
> Goetz <brian.goetz at oracle.com>; amber-spec-experts 
> <amber-spec-experts at openjdk.java.net>
> *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 <maurizio.cimadamore at oracle.com>
> *Sent:* 23 February 2023 20:27
> *To:* Brian Goetz <brian.goetz at oracle.com>; Angelos Bimpoudis 
> <angelos.bimpoudis at oracle.com>; amber-spec-experts 
> <amber-spec-experts at openjdk.java.net>
> *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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20230228/a50a33c9/attachment-0001.htm>