Value type hash code

[Dan Smith]

> On Apr 11, 2018, at 12:32 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
>> 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. 

It must do *something*, but throwing an exception (with 'equals' either throwing or returning 'false') is a viable 3rd alternative.