Value equality
Brian Goetz
brian.goetz at oracle.com
Mon May 16 19:00:37 UTC 2016
> 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.)
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').
More information about the valhalla-spec-observers
mailing list