Value type hash code

[forax at univ-mlv.fr]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Envoyé: Mercredi 11 Avril 2018 23:01:18
> Objet: Re: Value type hash code

> On Apr 11, 2018, at 11:27 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

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

> Not quite true: We are currently defining literal acmp on a value to return
> false always.
> That's to avoid having to buy the whole contract of detecting substitutability.

so acmp != substitutability, no ? 

> The performance model requires a new user-visible operator to test for the
> "thicker" concept of value substitutability.

and value substitutability can not be used for implementing equals because equals takes an Object as parameter while the thicker value substitutability is only define for different values of the same value type. 

> Meanwhile, reference substitutability has always been just a "thin" pointer
> compare.

You can say we have generalized substitutability which return false for value type or is a pointer comparison when you have reference, 
or you can say, we have only identity check for reference, so it returns null for value. 
Apart the fact that the name is different, it's the same thing, and i prefer identity check because it avoid to use the term of "thicker" value substitutability. 

Rémi