Value type hash code

[Remi Forax]

Hi Brian, 
in the l-world, you can have a reference or a value type in 'a' local,
so acmp is defined as an identity check (if there is a value type on the left or on the right operand the result is false) not a substitution check.
 
Rémi

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "daniel smith" <daniel.smith at oracle.com>, "David Simms" <david.simms at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Mercredi 11 Avril 2018 17:42:37
> Objet: Re: Value type hash code

> 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