Expression switch feedback
brian.goetz at oracle.com
Sun Apr 8 16:17:57 UTC 2018
> 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:
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
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
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.
More information about the amber-dev