Pattern Matching for switch (Second Preview)

[forax at univ-mlv.fr]

> From: "Tesla Ice Zhang" <ice1000kotlin at foxmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "jan lahoda" <jan.lahoda at oracle.com>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>
> Sent: Jeudi 23 Septembre 2021 08:32:41
> Subject: Re: Pattern Matching for switch (Second Preview)

> I am thinking about the following case:

> var e = verylong.expression;
> switch (e) {
> default -> println(e.getClass());
> case X x -> doSomething(x);
> }

> I would like to inline the variable `e`, but that's impossible as we used it
> twice. However, `e` is only needed in the default case, so what about allowing
> the following syntax, where we have a pattern in the default branch?

> switch (verylong.expression) {
> default e -> println(e.getClass());
> case X x -> doSomething(x);
> }

> This should be somehow equivalent to an Object type-case:

> switch (verylong.expression) {
> case X x -> doSomething(x);
> case Object e -> println(e.getClass());
> }

It's not exactly the same semantics because "Object e" allows null while "default" don't. 

> But I like the default syntax since it can be put to the beginning of the switch
> expression, and the type of `e` may not always be Object.

You will be able to use "var" instead of "Object" soon. 

Anyway, the question is should we allow the syntax "default variable" ? 

The example being if the switch is in a lambda or in a case (syntaxes that reward you if you write your code as a single expression) because introducing a local variable make the code uglier. 

By example, 
IntUnaryOperator op = x -> switch(x.foo(3)) { 
default -> { /* how to access to the value of x.foo(3) here ? */ } 
}; 

The current solution is to introduce a local variable, but it makes the code bulky 
IntUnaryOperator op = x -> { 
var result = x.foo(3); 
return switch(result) { 
default -> { /* use 'result' here */ } 
}; 
}; 

The reason to not do that is that is that the more "shortcut syntax" we introduce, the harder it is to read codes for everybody but the experts. 

> Regards,
> Tesla

regards, 
Rémi 

> ---Original---
> From: "Remi Forax"<forax at univ-mlv.fr>
> Date: Wed, Sep 22, 2021 16:37 PM
> To: "jan lahoda"<jan.lahoda at oracle.com>;
> Cc: "amber-dev"<amber-dev at openjdk.java.net>;
> Subject: Re: Pattern Matching for switch (Second Preview)

> And i think we should also fix the following

> 4. a case that mix constants and a type pattern (or a guard) of a supertype of
> the types of the constants should be allowed
> By example,
> case 3, Integer i ->
> or
> case 4, Object o ->

> 5. add an partial order edge between a guarded pattern and a constant of a
> subtypes of the type of the guarded pattern
> This code currently compiles
> switch(value) {
> case Integer i && bar() -> {}
> case 3 -> {}
> case Integer i -> {}
> }

> but i think it should be written
> switch(value) {
> case 3 -> {}
> case Integer i && bar() -> {}
> case Integer i -> {}
> }

> so the code is easier to read.

> Rémi

> ----- Original Message -----
> > From: "jan lahoda" <jan.lahoda at oracle.com>
> > To: "amber-dev" <amber-dev at openjdk.java.net>
> > Sent: Mercredi 22 Septembre 2021 18:11:13
> > Subject: Pattern Matching for switch (Second Preview)

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