[pattern-switch] Totality

[Guy Steele]

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.