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