Draft JLS Spec about unnamed patterns and variables
Brian Goetz
brian.goetz at oracle.com
Tue Feb 28 20:09:36 UTC 2023
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>
More information about the amber-spec-observers
mailing list