Switch syntax; pedagogical nightmare?

[Tagir Valeev]

Actually fall through case is not so trivial. Consider

switch (x) {
case Foo(var a, var b):
  System.out.println(a+":"+b);
  //fallthru
case Bar(var c, var d):
  System.out.println(c+":"+d);
  break;
}

So when we fall through, c and d are not defined. Thus this code should
result in compilation error. Seems that the scenarios when fall through is
actually  possible are quite rare.

Tagir Valeev.

3 авг. 2017 г. 6:43 AM пользователь "Brian Goetz" <brian.goetz at oracle.com>
написал:

>
> > I just watched the Java One talk by Brien, and can't help but feel that
> > overloading the 'switch' keyword for pattern matching is a hell of a
> > mistake. I realize the appeal in that it doesn't introduce a new keyword
> > due to backwards source compatibility, but feel like it's a pedagogical
> > nightmare.
> >
> > Having the break;s left off is clearly desirable for pattern matching
> that
> > involves destructing, but you are going to be leading so many newbies to
> > using switch statements (as opposed to expressions) without break,
> > expecting it to behave similar to the new expression usage of switch.
>
> I think you have misinterpreted what is being proposed.  Statement switch
> with patterns has exactly the same control flow behavior as it does without
> patterns — there is no relationship between whether the case labels are
> patterns and the break/fallthrough behavior.
>
> Similarly, if we introduce a switch *expression* (whose syntax would
> differ from statement switch), again this has nothing to do with patterns;
> it will behave the same way with patterns and without.
>
> So, the sky is not falling ;)
>
>