Type equality for values

[Brian Goetz]

Maurizio worked this out on the white board … it comes down to the semantics of vcmp.  Take a simpler example:

<any T, any U> void foo(T t, U u) { … t == u … }

When specialized with T=int, U=long, we’d get, assuming v* bytecodes are strongly typed (have a ref into the constant pool defining their expected operand type):

    vload n “I”
    vload m “J”
    vcmp “?”

There’s no value of “?” that won’t cause a verify error.  So the above is meaningless.

If A in your example is a value class, the same argument says we must fail; if A is a reference class, then we can fall back to the same rules as for reference comparison.

On Aug 1, 2014, at 11:07 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Certainly if we cannot prove T=U then I think this equality comparison makes no sense.  But if we have
> 
>  <any T> boolean foo(A<T> a, A<T> b) { return a==b; }
> 
> this does make sense (assuming we are comparing values for state equality via ==).
> 
> 
> On Aug 1, 2014, at 10:10 AM, Paul Govereau <paul.govereau at oracle.com> wrote:
> 
>> The following code is valid for reference types:
>> 
>> class A<T> {
>>   int x = 0;
>> 
>>   <T,U> boolean foo(A<T> a, A<U> b) {
>>       return (a == b);
>>   }
>> }
>> 
>> However, I don't think this makes sense for value types. In the case of reference types, the "top" is a realizable type, namely Object; but, for values the "top" is not realizable?
>> 
>> final __ByValue class A<T> {
>>   final int x = 0;
>> 
>>   <any T, any U> boolean foo(A<T> a, A<U> b) {
>>       return (a == b);  // <<--- type error ??
>>   }
>> }
>> 
>> Should this be a type error?
>> 
>> Paul
>