Feedback wanted: switch expression typing

[Dan Smith]

(Looking for some feedback on real-world code usage. Please read to the end, then if you can experiment with the code you work on and report back, I'd appreciate it!)

Switch expressions, from a type checking perspective, are basically generalizations of conditional expressions: instead of 2 operands to check, we have n.

A reasonable expectation is that, if I rewrite my conditional expression as a switch expression, it will behave the same:

test ? foo() : bar()
is equivalent to
switch (test) { case true -> foo(); case false -> bar(); }

So, as a starting point, the typing rules for switches should be the same as the typing rules for conditionals, but generalized to an arbitrary number of results.

(The "results" of a switch expression are all expressions appearing after a '->' or a 'break'.)

Conditional expressions and switch expressions are typically used as poly expressions (in a context that has a target type). But that won't always be the case. One notable usage that doesn't have a target type is an initializer for 'var': "var x = ...". So they are sometimes poly expressions, sometimes standalone.

Conditional expression typing is driven by an ad hoc categorization scheme which looks at the result expressions and tries to predict whether they will all have type boolean/Boolean, primitive/boxed number, or something else/a mix ("tries to predict" because in some cases we can't type-check the expression until we've completed the categorization).

In the numeric case, we then identify the narrowest primitive type that can contain the results.

In the other/mixed case, we then type check by pushing down a target type, or, if none is available, producing a reference type from the lub operation.

A couple of observations:

- The primitive vs. reference choice is meaningful, because the primitive and reference type hierarchies are different (e.g., int can be widened to long, but Integer can't be widened to Long). Preferring primitive typing where possible seems like the right choice.

- The ad hoc categorization is a bit of a mess. It's complex and imperfect. What people probably expect is that, where a target type is available, that's what the compiler will use—but the compiler ignores the target type in the primitive cases.

Why? Well, in 8, when we introduced target typing of conditionals, we identified some incompatibilities that would occur if we changed the handing of primitives, and we didn't want to be disruptive.

Some examples:
Boolean x = test ? z : zbox; // specified: can NPE; target typing: no null check
Integer x = test ? s : i; // specified: ok; target typing: can't convert short->Integer
Number x = test ? s : i; // specified: box to Integer; target typing: box to Short or Integer
double d = test ? l : f; // specified: long->float loses precision; target typing: long->double better precision
m(test ? z : zbox); // specified: prefers m(boolean); target typing: m(boolean) and m(Boolean) are ambiguous

At this point, we've got a choice:
A) Fully mimic the conditional behavior in switch expressions
B) Do target typing (when available) for all switch expressions, diverging from conditionals
C) Do target typing (when available) for all switches and conditionals, accepting the incompatibilities

(A) sacrifices simplicity. (B) sacrifices consistency. (C) sacrifices compatibility.

General thoughts on simplicity (is the current behavior hard to understand?) and consistency (is it bad if the conditional/switch refactoring leads to subtly different typing?) are welcome.

And we could use some clarification is just how significant the compatibility costs of (C) are. With that in mind, here's a javac patch:

http://cr.openjdk.java.net/~dlsmith/logPrimitiveConditionals.patch

A javac built with this patch supports an option that will output diagnostics wherever conditionals at risk of incompatible change are detected:

javac -XDlogPrimitiveConditionals Foo.java

If you're able to build OpenJDK with this patch and run it on some real-world code, I'd appreciate any insights about what you find.

—Dan