no good default issue

[Brian Goetz]

> Personally, I view such tactics as possible but expensive,
> and would like to try to get by without JVM support for
> them, to start with.  The JVM engineering teams are already
> overworked for Valhalla.
>

And, more than that.  The technique of "ask a no-arg ctor" (or some 
other stateless source) only works for the classes in Bucket 2, which, 
as Dan and Kevin have pointed out, are actually the smaller and far less 
interesting group than Bucket 3, where there is simply no good default, 
and anything returned by the no-arg ctor would just be a different 
flavor of ad-hoc null.

One example of such a class is:

     inline record Name(String first, String last) { }

What would be the default?  Two empty strings?  Strings containing 
"<no-name>"?  Are those really better than (null, null)?

Kevin has argued that Date equally belongs in this bucket.  Sure, we can 
interpret 1970 as the default date, but in the situations where someone 
uses an uninitialized date, what percentage of the time are they 
satisfied with 1970 as the result?  I don't think it's going out on a 
limb to say "not that often."  And if the date is used as an input to, 
say, an interest calculation, that's pretty bad.

The lesson of the most recent discussion is that "let the user pick the 
default" is not really better, and often worse, than "let zero be the 
default."  Really, this is not about defaults, but about detecting use 
of uninitialized data.

Refs don't have this problem, because when you try to do anything 
nontrivial with a null (other than move it around or compare it to 
another ref), the VM tells you clearly that you tried to use 
uninitialized data.

By the NNN Directive, winning looks like, to the extent we do anything 
here, aligning the behavior of dereferencing an uninitialized NGD value 
with that of dereferencing a null.