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 <[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
