Expression switch feedback

[Brian Goetz]

> 3. break "Green"???

Once we let go of the fact that WE as teachers have to learn something 
new, I think this actually gets easier to teach, because it is exactly 
like something else in the language we already know and have no problem 
with.  Here's how I'd teach it: by comparison to "return".

Return takes two forms:

     return;
     return "Green";

The former is allowed in a void method or lambda and is an error in a 
value-bearing one.  The latter is an error in a void method or lambda 
and allowed in a value-bearing bearing one.  This isn't even a little 
bit confusing.

Now, your students don't know about how it used to be.  So you'll tell 
them break is like return:

  - return stops executing a method (or lambda expression)
  - break stops executing a switch
  - if the method yields a value, return must provide one
  - if the method yields no value, return must not provide one
  - if the switch yields a value, break must provide one
  - if the switch yields no value, break must not provide one

This is even simpler than it is now (because the same rule works in 
multiple places), and, if presented sensibly, no one will ever think 
twice about it.  As a teacher, you should be rejoicing at this.

I place a lot of value on the language being approachable and 
teachable.  But as teachers, its very easy to be biased by the challenge 
of _us_ having to learn new stuff too -- not only learning the new 
features, but learning new ways of teaching.  But of course it's not 
about us, its about the students, so "but we'll have to learn new ways 
of teaching" should be a total zero in the calculus.

There's not a right answer here; there's only tradeoffs, and there's 
room for lots of subjective preferences.  But, the "euww, it's 
different" reactions are the least helpful in navigating the tradeoffs.  
Things like "break green" look weird for about the first ten seconds.  
(No one thought the current lambda syntax looked natural at first, 
either.)  That ten seconds represents a very small fraction of our 
programming or teaching careers, but seems to take a disproportionate 
bandwidth in our discussions....

> My strong recommendation would be to leave statement switch alone.

This isn't an option, but I could see how you could arrive at this idea 
if you thought the main goal was expression switch".  Yes, what we're 
delivering _first_ is the expression support, but that's not the end 
goal -- the end goal is pattern matching.  And "leaving switch statement 
alone" means that switch statement doesn't get support for patterns, so 
that's a non-starter -- we'll have to upgrade switch _anyway_, unless we 
want four constructs.  So what you're really suggesting is "change 
switch _and_ also make a new construct for multi-way conditional 
expressions" in preference to upgrading switch in two dimensions.  (That 
may be a sensible path, but is not as simple as "leave it alone" makes 
it sound.)

In any case, your feedback of "please reconsider whether a separate 
multi-conditional expression construct might be preferable" is taken, 
and we will continue to think about it.

Anyway, going back to my weekend now.

Cheers,
-Brian