Switch expressions -- some revisions

[Brian Goetz]

> The "return/return e/break/break e" analogy Brian just gave helps as well.

My take-away from Kevin's reaction is: some will immediately see how 
"break n" is just a generalization of existing break, and some people 
will not immediately see it -- and when you don't, it feels uncomfortable.

Being in the first category, I had a hard time imagining being in the 
second category, but here we have a good existence proof that it can be 
reasonably inhabited, so we need to consider the pedagogical 
tradeoffshere too.

(What I like about where this proposal leads is that it is building 
expression switch atop existing switch, and only adding the minimum new 
stuff needed to support expression-ness (yielding a value, enhanced flow 
analysis), plus a little sugar.)

Ironically, the fact that the "case L -> e" form will be so prevalent 
makes it harder to get comfortable with the traditional syntax, because 
it will occur so rarely.  (This is an example where we get so hooked on 
our sugar we forget it is sugar.)


> starting to see that `return` is more problematic than I first realized

I didn't see this one at first either; it only hit me later when I 
thought about refactoring between expression and statement switch.  And, 
like those figure/ground optical illusions, once you see it, you can't 
unsee it...