Revisiting default values

[Brian Goetz]

> I think it would help if we had a clear sense as to what proportion of 
> inline-types we think will have this "bad default" problem. Last year 
> when we discussed null-default inline types the thinking was that 
> about 75% of the motivation for null-defaults was migrating VBC, 20% 
> for security, 5% for "I want null in my value set.". My assumption is 
> that the vast majority of inline-types will not be migrated types, 
> they will be new types. If this is correct then it would appear that 
> the default value problem is really a problem for a minority of 
> inline-types. 

Indeed, we've come up with good solutions for migrating VBCs (migrate it 
to a ref-default inline class) and "I want null in my value set" (then 
just use the ref projection.)

For the "migrate from VBC" crowd, we offer the advice: "keep using `Foo` 
(really `Foo.ref`) in your APIs, but feel free to use `Foo.val` inside 
your implementation, where you are confident of no nulls."  And further, 
we offer that advice to both the VBC author and its clients.  So, we can 
expect existing APIs to continue to return Optional<T>, but more fields 
of type `Optional.ref<T>`, to get the flattening, and doing null checks 
in the constructor:

     this.foo = requireNonNull(foo)

And this is one of the sources of "zero pollution"; a client may have a 
field of type `Foo.val` and just not initialize it in their constructor, 
and then later someone calls `foo.bar()`.  Unlike with a reference type, 
which would NPE in this situation, we might enter the `bar()` method, 
which might not be defensively coded to check for the (meaningless) 
default, and it will do something dumb.  Where dumb ranges from "Welcome 
to 1970" to "delete all my files."

I think what we need for Bucket 3 (which I think we agree is more 
important than Bucket 2) is to (optionally, only for NGD inline classes) 
restore parity with reference types by ensuring that the receiver of a 
method invocation is never seen to be the default value.  (We already do 
this for reference types; we NPE before the dispatch would succeed.)   
And the strategies we've been kicking around have ranged from "try to 
prevent the default from showing up in the heap" to "detect when the 
default shows at various times."

If the important point in time is method dispatch, then we can probably 
simplify to:

  - Let some classes mark themselves as NGD (no good default)
  - At the point of invocation of an NGD instance method, check the 
receiver against the default, throw NPE if it is
  - Optionally, try to optimize this check by identifying (manually or 
automatically) a pivot field

Note that even an unoptimized check is probably pretty fast already: 
"are all the bits zero."  But we can probably often optimize down to a 
single-word comparison to zero.

Note too that we can implement this check in either generated bytecode 
or in the VM; the semantics are the same, the latter is more secure.