Value type hash code

[Dan Smith]

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

—Dan