Pattern Matching for switch (Second Preview)

[Remi Forax]

----- Original Message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "jan lahoda" <jan.lahoda at oracle.com>, "amber-dev" <amber-dev at openjdk.java.net>
> Sent: Mercredi 22 Septembre 2021 21:25:42
> Subject: Re: Pattern Matching for switch (Second Preview)

> I have several things I'd like to see make it into this round.
> 
> 1.  Totality for GADTs.  If we have a hierarchy:
> 
>     sealed interface Foo<T> { }
>     class A<T> implements Foo<T> { }
>     class B<T> implements Foo<T> { }
>     class C implements Foo<String> { }
> 
> then when switching over a Foo<String>, we need all of A/B/C to be
> total, but when switching over a Foo<Shoe>, we only need cover A and B
> in order to be total, because C is not a possible choice.  When
> considering totality, we should only consider the options whose
> parameterizations are consistent with that of the target.

yes,

> 
> 2.  Inference for type patterns.  This one may be a little
> controversial, because we already let this ship sail with type patterns
> in instanceof, but I'm pretty convinced that what we're doing right now
> is wrong.  Currently, if we are switching on a List<String>, we disallow
> a type pattern for ArrayList<Frog>, because this would require an
> unchecked conversion.  This is right.  But if we have a `case ArrayList
> a`, the type of `a` is not ArrayList<String>, but raw ArrayList.  This
> is almost always not what the user wants; there's no migration
> compatibility here where the switch target was generified but the case
> labels are not.  Like we do with method references, we should infer a
> reasonable parameterization of ArrayList from the match target when a
> "naked" type shows up in a type pattern.  (If the user really wants a
> raw ArrayList, they can switch on a raw List.)
> 
> Fixing this for switch is no problem, as it is in preview, but fixing
> this in instanceof requires more care, since there may be production
> code out there.  However, we've generally held that it is OK to infer
> _more_ specific types than have previously been inferred; I doubt much
> code would be impacted -- more likely, some silly casts would go away,
> since users no longer have to cast to ArrayList<String>.

I agree,
as you said it's not a compatible change,
by example, the following codes will not be valid anymore.

  List<String> l = ...
  if (l instanceof ArrayList a) {
    a.add(3);  // it's a warning, it will become an error
  }

and
  static void foo(Comparable<String> c) { }
  
  Object o = ...
  if (o instanceof Comparable c) {
    foo(c);  // it's a warning, it will become an error
  }
  
In all cases, it seems to be an unsafe code that get a warning upgraded to an error.


> 
> 3.  Also, Dan raised a coverage question here:
> 
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-July/003049.html
> 
> In this example (asterisk means abstract):
> 
>     A* = B1* | B2* | C*
>     B1* = D1
>     B2* = D2
>     C* = D1 | D2
> 
> In order to cover A, we need to cover B1|B2|C.  Given
> 
>     case B1:
>     case B2:
> 
> B1 and B2 are clearly covered; the question is C.  And C=D1|D2. B1
> covers D1, and B2 covers D2, so B1|B2 covers D1|D2, and therefore B1|B2
> covers C.

yes

Rémi

> 
> 
> 
> On 9/22/2021 12:11 PM, Jan Lahoda wrote:
>> Hi,
>>
>> There is a new draft JEP for preview 2 of Pattern Matching for switch
>> here:
>> https://bugs.openjdk.java.net/browse/JDK-8273326
>>
>> The exact changes that will be done under this round of preview are
>> yet to be determined, but changes related to generics handling in
>> pattern matching switches seem to be plausible.
>>
>> Feedback is welcome!
>>
>> Thanks,
>>     Jan