Option 8: The statement “switch case (x) { … }” is like “switch (x) { … }” but
insists that the value x be handled by some case clause. The switch body
cannot contain a default clause (static error if it does), and it’s impossible
for the switch statement to silently do nothing. It’s a static error if the
set of case patterns is not at least optimistically total, and you get residue
checking.
enum Color { RED, GREEN }
Color x;
switch (x) { case RED: … } // Okay
enum Color { RED, GREEN }
Color x;
switch case (x) { case RED: … } // static error: cases are not
optimistically total
Note that you can still use int and String types, but because default clauses
are forbidden, you have to use a total pattern instead:
switch case (myString.length()) {
case 2: case 3: case 5: case 7: primeSquawk();
case 4: case 9: squareSquawk();
case int n: squawk(n);
}
I think this option clearly dominates options 4 and 7 (“switch enum (x)” and
“switch ((Color) x)”).
Note that it’s not completely redundant to allow “switch case” expressions as
well (which would ease refactoring), but the only extra constraint added by
“switch case” is that a default clause cannot appear. If this option were
adopted, I suspect it would quickly become idiomatic to use “switch case” on
enums and many sealed types, and to use “switch” with a “default
<totalpattern>” clause in most other cases.
