Next up for patterns: type patterns in switch

[Guy Steele]

> On Aug 12, 2020, at 3:57 PM, forax at univ-mlv.fr wrote:
> . . .
> 
> I agree destructuring is just as important as conditionality and those two things should be orthogonal.
> But i still think having a keyword to signal that a pattern (not a case) is total is better than letting people guess.

Yes, and here is the example that convinced me that one needs to be able to mark patterns as total, not just cases:

(Assume for the following example that any pattern may be preceded by “default”, that the only implication of “default” is that you get a static error if the pattern it precedes is not total, and that we can abbreviate “case default” as simply “default”.)

	record Box<T>(T t) { }
	record Bag<T>(T t) { }

	record Pair<T,U>(T t, U u) { }

	Triple<Box<Frog>, Bag<Object>> p;

	switch (x) {
		case Pair(Box(Tadpole t), Bag(String s)): …
		case Pair(Box(Tadpole t), Bag(default Object o)): …
		case Pair(Box(default Frog f), Bag(String s)): …
		default Pair(Box(Frog f), Bag(Object o)): …
	}

I think there is some charm to this.

To be clear, the intent of this variant proposal is that _any_ pattern may have “default” in front of it, but I suspect that in practice its primary use will be within “switch” (or at least within some sort of conditional context), which is what justifies the use of the keyword “default”.  Certainly

	default Pair(T x, U y) = expr;

is not especially useful, because if Pair(T x, U y) is not total on the type of expr we presumably get a static error from the declaration even without the keyword “default” present.  Possibly someone might write

	if (x instanceof FrogBox(Toad t)) …
	else if (x instanceof FrogBox(Tadpole tp)) …
	else if (x instanceof default FrogBox(Frog f)) ...

or

	if (x instanceof FrogBox(Toad t)) …
	else if (x instanceof FrogBox(Tadpole tp)) …
	else if (x instanceof FrogBox(default Frog f)) ...

and either of those might actually be useful (in fact, I believe they are equivalent but differ in stylistic emphasis), but then that someone should remember that instanceof is never true when x is null (which may be what is wanted in this specific code).

So “default” is in practice used much like “any” that Rémi earlier discussed, but the theory is that “default” does not dictate null-acceptance; rather, null-acceptance depends on pattern totality (in the manner Brian has argued for), and “default” is a way for the programmer to ensure pattern totality.