break seen as a C archaism

[Brian Goetz]

>
> I don't know why others find break so archaic. When I 1st saw this 
> proposal, I thought that break was very intuitive choice for e-switch.

I think this is mostly an emotional reaction.  There are plenty of 
things to dislike about switch in Java; I think that for some, the 
prospect of switch getting an overhaul but not "fixing" the things about 
it you hate most, feels like a slap in the face.  (I think there's also 
a bit of wishful thinking, that if we had a new shiny expression, we'd 
forget that it is almost but not quite like this existing construct that 
we can almost but not quite forget about.) It's like when you get an 
upgrade to a software package I use a lot, I see they've changed all the 
cosmetic stuff, but the annoying behaviors are still there, and you 
wonder, "what was the point of that upgrade?"  But, the goal was not to 
fix switch, as much as extend it to do new things, and that means the 
things it already did, it should keep doing them that way.

As a reminder: while switch expressions are great (which is why we 
factored them out of the larger pattern effort), they are the 
"opportunistic" feature here; the real story is pattern matching (whose 
first target will be algebraic data types -- records and sealed classes).

> Speaking of long returns...
>
> If return was used for "yielding" a result from e-switch, how is one 
> supposed to do a return from a method inside the e-switch:
>
> int m(int x) {
>     int y = switch (x) {
>         case 1: return 12; // I want to return from m() here!
>     }
> }

Not allowed.  A switch expression, like a conditional expression (or any 
expression, for that matter), must yield a value or throw.  It can't do 
nonlocal control flow into enclosing contexts, except throwing.

> And now for something completely different...
>
> I think that with introduction of e-switch, we might soon see it being 
> "abused" for things like:
>
> doSomething(
>     par1,
>     switch (1) { case 1:
>         // compute result...
>        break resut;
>     },
>     par3
> );
>
> Are there any plans for such construct "without the boilerplate" ?-)

Yes, switch expressions can be abused to become block expressions; 
switch (0) { default: s; s; break e; } becomes a block expression. 
That's ugly enough that maybe it will discourage people from doing this....

We don't have plans to fix it, but we're open to ideas; a more natural 
way to treat blocks of statements like:

     var x = new Foo();
     x.setA(3);
     return x;

as an expression would have removed a lot of the angst over this 
feature.  Maybe it could be written

     with (new Foo()) { setA(3); }

or something.  But, its not the top priority right now.

> Among existing reserved words, "do" seems most appropriate:

Yes, do { } could become an expression with "break e".  (And maybe even 
make the while optional.)