Static effects of <type>.default

Jesper Steen Møller jesper at selskabet.org
Sat Jan 18 23:16:43 UTC 2020


Sorry, the example was obviously wrong, and should have been:

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


> On 18 Jan 2020, at 23.43, Jesper Steen Møller <jesper at selskabet.org> wrote:
> 
> 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 <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
> 



More information about the valhalla-dev mailing list