JEP325: Switch expressions spec

[Guy Steele]

> On May 10, 2018, at 10:11 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> This was the thinking behind UA1; that sometimes you were going to want to "fall into" an arrow case

"What I propose IS NOT FALLTHROUGH!” he continues to howl into the darkness (but otherwise keeps his mouth zipped, because he is done arguing** :-).

—Guy

** As promised, I will offer no further argument as to what syntax should be adopted (that's policy); but I will continue to proclaim firmly that multiple labels in a SwitchBlockStatementGroup are not, and never have been, an example of fallthrough (that’s a fact, supported by textual evidence in the JLS from the very beginning).

Here’s why we (Bill Joy and I) did that: If you look at the underlying implementation in the JVM, when you use a “lookupswitch” instruction, if two int values happen to take you to the code for the same statement, then for either int value the lookup table takes you straight there; there is no “fallthrough” at the JVM level, and the terminology used in the source language documentation reflects that intent, the better to convey the intended execution and cost model.  When you write “case 3: case 4: S” it means EXACTLY the same thing as “case 4: case 3: S” and ought to have exactly the same cost, no matter what the run-time distribution of occurrences of “3” and “4” as actual dispatch values.  The labels “case 3:” and “case 4:” are co-equal labels of S.  There is no extra execution step of any kind when the dispatch value equals the case label that happened to be written first, compared to what happens when the dispatch value equals the case label that happened to be written second.  And of course the intent was that the same thing would be going on at the machine level: there would simply be a jump instruction to an address pulled from a table.

The introduction of patterns may disrupt that model.  If so, so be it, but that is a big-deal change, and it will need to be explained carefully.