Pattern Matching for switch (Second Preview)

[Tagir Valeev]

Hello, Remi!

> 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 */ }
> };
> };

By the way, Kotlin allows declaring variable right in 'when'
expression ('when' is somewhat similar to Java switch):
when(val x = very long expression) {
is Foo -> {}
is Bar -> {}
else -> {}
}

Its scope is naturally limited to the 'when' expression itself, so
it's a little bit more than a syntactic sugar for separate
declaration. Somehow, it's similar to the 'for' loop initializer.
Well, in Kotlin, such declarations are more important due to the way
smart casts work.

With best regards,
Tagir Valeev.

On Thu, Sep 23, 2021 at 2:03 PM <forax at univ-mlv.fr> wrote:
>
> > 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