Value type hash code

[Remi Forax]

----- Mail original -----
> De: "daniel smith" <daniel.smith at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Mercredi 11 Avril 2018 18:40:25
> Objet: Re: Value type hash code

>> On Apr 11, 2018, at 9:42 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> One of the operations we can name is ==.  I think the substitution check is the
>> most reasonable interpretation of ==, but I don't really see how we can avoid
>> recurring on .equals() for the equals() implementation.  Otherwise, this will
>> violate basic user expectations, such as:
>> 
>>     value record StringBox(String s);
>> 
>> I think values would be near-useless under such an interpretation of equals().
> 
> This is a reasonable language design, but I don't think the JVM should hard-wire
> that behavior. The compiler can generate the equals/hashCode methods it wants,
> and my thinking is that when the compiler fails to do so, the JVM's default
> (that is, the behavior of Object.equals and Object.hashCode if not overridden)
> should be conservative.

I think we can go a step further and do not provide any defaults.

The default implementation of equals and hashCode in java/lang/Object make only sense for reference,
for value types, it depends on the value type, i.e, it's far easier for the compiler to provide an equals/hashCode than for the VM,
hence my proposition that the VM should not provide any default and let the compiler of the different languages decide what defaults are. 

> 
> —Dan

Rémi