Value equality

[Brian Goetz]

The discussion on equality will continue to play out on the EG list, so 
I won't respond further on the details here, except to observe:

The success or failure of this project will turn on user's success with 
of migrating existing code to values / any-generics.  So yes, making 
migration successful and non-intrusive is (and must be) a primary 
consideration in all of our design choices here.



On 5/16/2016 4:21 PM, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "Brian Goetz" <brian.goetz at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>, "Valhalla Expert Group Observers" <valhalla-spec-observers at openjdk.java.net>
>> Cc: "Kevin Bourrillion" <kevinb at google.com>
>> Envoyé: Lundi 16 Mai 2016 21:00:37
>> Objet: Re: Value equality
>>
>>
>>> another possible choice is to not allow == on value type (and on a T bound
>>> by any),
>>> it makes the semantics far easier to understand, you can only use == on
>>> something which fit into a 32/64 bits,
>>> in that case primitive types need to have an equals.
>>>
>> This wouldn't go well when migrating existing generic code to
>> any-generic.  Consider code like:
>>
>> class Bag<T> {
>>       void contains(T t) {
>>           for (T e : this)
>>               if (t == e || t.equals(e))
>>                   return true;
>>           return false;
>>       }
>>
>> When we anyfy this code, if == were not allowed on values, this code
>> would break.  (You might suggest in this case we constant-fold it to
>> false, but that is not likely to seem intuitive either.)
> t == e is here just because equals() can be slow (or not inlined),
> premature optimization is the root of Evil :)
>
>> Would be nice to minimize the amount of change to anyfy this case,
>> beyond sticking an 'any' in front of T -- existing well-behaved generic
>> code should require little or no change (for some definition of
>> 'well-behaved').
>>
>>
>>
> I'm not sure to buy that we should add == to value type because it will make migration easier.
>
> Rémi