Treatment of total patterns (was: Reviewing feedback on patterns in switch)

[Brian Goetz]

1.  Treatment of total patterns in switch / instanceof

The handling of totality has been a long and painful discussion, trying to balance between where we want this feature to land in the long term, and people’s existing mental models of what switch and instanceof are supposed to do.  Because we’ve made the conscious decision to rehabilitate switch rather than make a new construct (which would live side by side with the old construct forever), we have to take into account the preconceived mental models to a greater degree.

Totality is a predicate on a pattern and the static type of its match target; for a pattern P to be total on T, it means that all values of T are matched by P.  Note that when I say “matched by”, I am appealing not necessarily to “what does switch do” or “what does instanceof do”, but to an abstract notion of matching.

The main place where there is a gap between pattern totality and whether a pattern matches in a switch has to do with null.  We’ve done a nice job retrofitting “case null” onto switch (especially with `case null, Foo f` which allows the null to be bound to f), but people are still uncomfortable with `case Object o` binding null to o.

(Another place there is a gap is with nested patterns; Box(Bag(String s)) should be total on Box<Bag<String>>, but can’t match Box(null).   We don’t want to force users to add default cases, but a switch on Box<Bag<String>> would need an implicit throwing case to deal with the remainder.)

I am not inclined to reopen the “should `Object o` be total” discussion; I really don’t think there’s anything new to say there.  But we can refine the interaction between a total pattern and what the switch and instanceof constructs might do.  Just because `Object o` is total on Object, doesn’t mean `case Object o` has to match it.  It is the latter I am suggesting we might reopen.

The motivation for treating total patterns as total (and therefore nullable) in switch comes in part from the desire to avoid introducing sharp edges into refactoring.  Specifically, we had two invariants in mind:

    x matches P(Q) === x matches P(var alpha) && alpha matches Q:

and

    switch (x) {
        case P(Q): A
        case P(T): B
    }

where T is total on the type of x, should be equivalent to

    switch (x) {
        case P(var alpha):
            switch(alpha) {
                case Q: A
                case T: B
            }
        }
   }

These invariants are powerful both for linguistic transformation and for refactoring.

The refinements I propose are:

 - Null is only matched by a switch case that includes `case null`.  Switches with no `case null` are treated as if they have a `case null: throw NPE`.  This means that `case Object o` doesn’t match null; only `case null, Object o` does.

 - Total patterns are re-allowed in instanceof expressions, and are consistent with their legacy form.

Essentially, this gives switch and instanceof a chance to treat null specially with their existing semantics, which takes precedence over the pattern match.

The consequences of this for our refactoring rules are:

 - When unrolling a nested pattern P(Q), we can only do so when Q is not total.
 - When unrolling a switch over nested patterns to a nested switch, `case P(T)` must be unrolled not to `case T`, but `case null, T`.


These changes entail no changes to the semantics of pattern matching; they are changes to the semantics of instanceof/switch with regard to null.