Type equality for values

John Rose john.r.rose at oracle.com
Tue Aug 5 08:26:40 UTC 2014


On Aug 1, 2014, at 4:16 PM, Alex Meiburg <timeroot.alex at gmail.com> wrote:

> Wouldn't that idea that "mutually castable types" suggest that int and long
> should work, though -- in the sense that they can still be cast from one to
> the other, even if this casting isn't because of a shared top type?

The JLS mentions "casting" only with respect to references (15.21.3).

The language about primitive comparisons (15.21.1) uses much more complex rules, with no casting, to define mixed primitive equality testing.

Neither type of comparison fits well to values.  So we need to define v==v in the absence of a common top type, and also in the absence of numeric-style promotion rules.  What's left is that the two operands must be exactly the same type.  (If we add value subtyping or value promotion, we can reconsider, but we probably won't.)

Odd corner case:  A value can be boxed to its box type, and also boxed to any of its implemented interfaces.  Does this interact with the present rules for ==?  What is the meaning of Integer.valueOf(42) == 42?  Hopefully it is illegal.

— John

> -- Alexander Meiburg
> 
> 
> 2014-08-01 13:54 GMT-07:00 Brian Goetz <brian.goetz at oracle.com>:
> 
>> If the thing being compared is a value, I think we want “must”; if the
>> things being compared are refs, then “may”.
>> 
>> On Aug 1, 2014, at 12:05 PM, Paul Govereau <paul.govereau at oracle.com>
>> wrote:
>> 
>>> Sorry, I am a little confused. I sounds like Brian is saying that
>>> T=U _must_ be true, and Maurizio is saying we only need that
>>> T=U _may_ be true?
>>> 
>>> Is this a case where value- and reference-types differ?
>>> 
>>> Paul
>>> 
>>> On 08/01/2014 02:27 PM, Maurizio Cimadamore wrote:
>>>> 
>>>> On 01/08/14 11:23, Maurizio Cimadamore wrote:
>>>>> Right - I would expect that to already be working (modulo the fact
>>>>> that I have not really tested integration of 'any' with value types
>>>>> that much - yet).
>>>> Let me backtrack a bit - currently the spec (15.21.3) demands that the
>>>> equality should be accepted if one type is castable to the other. I
>>>> believe in all the examples I've seen so far, that's the case, as there
>>>> is always a chance that the type-variable will be instantiated with the
>>>> same type, so the cast must be allowed.
>>>> 
>>>> Maurizio
>>>>> 
>>>>> Maurizio
>>>>> 
>>>>> On 01/08/14 11:07, Brian Goetz 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
>>>>> 
>>>> 
>> 
>> 



More information about the valhalla-dev mailing list