Static effects of <type>.default

[Jesper Steen Møller]

Hi Valhalla

In the State of Valhallla writeup, the ".default” exists for all types <http://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html>:

> Every type has a default value. For primitive types, the default value is some sort of zero (0, 0.0, false, etc); for reference types, the default value is null. For inline classes, the default value is the instance of that type where all fields take on the default value for their type. For any class type C, the default value of C may be denoted as C.default. (In generic code, we may refer to T.default. For erased generics, T is always a reference type and therefore this evaluates to null; when generics are specialized, T.default will be specialized as well.)


So, does it make sense for the compiler to be able to reason about these defaults, or is it just an unnecessary “optimisation”. E.g. would you expect the compiler to detect the unreachable code here:

while(int.class != 0)
{
    System.out.println("Inside while block");
}

Pro: Why not, it makes sense for the current primitive types and reference types.
Con: Not only is it unlikely to catch real errors, but it wouldn’t be symmetric to the case of inline classes where the value of SomeInlineType.default.field relies on code in a different class.
For specialized generics some day: ???

Discuss?

Kind regards,
Jesper