Value type hash code

[Brian Goetz]

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

On 4/11/2018 10:13 AM, Dan Smith wrote:
>> On Apr 10, 2018, at 8:49 AM, David Simms <david.simms at oracle.com> wrote:
>>
>> * Values containing references whose contents are mutable pose a
>>    problem, their hash code is only as stable as the contents of the
>>    whole object graph.
> There's some flexibility in how we name operations, but let's observe that there are two pairs of operations to consider:
>
> substitutable/substitutableHash: recur on value fields, use acmp on reference fields
> deepEquals/deepHash: recur on value fields, use 'equals' on reference fields
>
> I think my expectation has been that substitutable/substitutableHash would be the default behavior of equals/hashCode, with the capability for users to override this if they're confident it's safe. (And with the ability to fall back to the default behavior with System.identityHashCode or something similar.)
>
> —Dan