Draft JLS Spec about unnamed patterns and variables

Fri Mar 24 14:41:14 UTC 2023

Thanks for your comments. I updated our draft with unnamed patterns actually getting resolved now. They weren't before.
`when (Boolean) null` -- yuck :)  Well spotted.
What did you mean by this? 😄 (Boolean) is not a constant expression.

Updated version: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

(this points to a new directory that names the JEP number, I updated our "latest" redirect script, but I had to clear the cache of my browser to finally see it! :O, just in case it occurs to others too)
________________________________
From: Brian Goetz <brian.goetz at oracle.com>
Sent: 28 February 2023 21:09
To: 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

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><mailto:angelos.bimpoudis at oracle.com>
Sent: 24 February 2023 17:23
To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com><mailto:maurizio.cimadamore at oracle.com>; Brian Goetz <brian.goetz at oracle.com><mailto:brian.goetz at oracle.com>; amber-spec-experts <amber-spec-experts at openjdk.java.net><mailto: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><mailto:maurizio.cimadamore at oracle.com>
Sent: 23 February 2023 20:27
To: Brian Goetz <brian.goetz at oracle.com><mailto:brian.goetz at oracle.com>; Angelos Bimpoudis <angelos.bimpoudis at oracle.com><mailto:angelos.bimpoudis at oracle.com>; amber-spec-experts <amber-spec-experts at openjdk.java.net><mailto: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-experts/attachments/20230324/904176f8/attachment-0001.htm>