Value equality
forax at univ-mlv.fr
forax at univ-mlv.fr
Thu May 19 07:31:39 UTC 2016
Doubling equals() for the value type in case of LIFE is one solution, i think there is another one.
Currently, we have this semantics
op | prim type | ref type
== | == | ==
equals | X | equals
if we introduce value type, one possible solution is
op | prim type | ref type | value type
== | == | == | equals
equals | X | equals | equals
so in case of LIFE, equals is called twice.
The other solution is to consider that == is an identity check, so
op | prim type | ref type | value type
== | == | == | X
equals | X | equals | equals
the problem is that in case of an any type, we can not use == nor equals, at least if we consider that the semantics of any is the same as the one if there are substitution of any by the type argument.
as you said, we can introduce a new operator, the only semantics for this newop seems to be
op | prim type | ref type | value type
== | == | == | X
equals | X | equals | equals
newop | == | == || equals | equals
now if we do not want to introduce a new operator we have to provide a semantics for the two 'X', if == is an identity check, instead of mapping == on a value type on equals, it can be map on (a, b) -> false,
op | prim type | ref type | value type
== | == | == | false
equals | == | equals | equals
in that case, LIFE for a primitive type is a == b || a == b, LIFE for a ref type is a == b || a.equals(b) and LIFE for a value type is false || a.equals(b), all these patterns are trivially optimizable by a JIT.
Note that this is the semantics at bytecode level, at Java level, it can be the semantics for any and still doesn't allow == on value type and equals on primitive type,
this has the advantage of having only one way to do an equality at Java level for primitive types and value types.
regards,
Rémi
More information about the valhalla-spec-observers
mailing list