no good default issue

[Remi Forax]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "John Rose" <john.r.rose at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Samedi 1 Août 2020 16:41:11
> Objet: Re: no good default issue

>> 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.

It depends if throwing an exception in the default constructor is allowed or not ?
i.e. if an exception is a valid state for a default value, like an exception is a valid value when evaluating a condy/ldc.

> 
> 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.

Rémi