Yes, it's a tempting direction. John and I both walked that road, in
the hope that there was a reasonable place to cut off the regress. (And
we both walked back disappointed.)
One problem is that with erased generics, all Ts become Object:
/* erased */ value class Box<T> {
T t;
}
translates to
value class Box {
Object t;
}
So no two boxes would be == to each other -- in fact, a given Box would
not be == to itself. I think users would find
Optional<Point> o = Optional.of(p);
o == o // false
to be surprising! Similarly, classes like
value record Twople<T,U>(T t, U u);
Twople<String, String> x = new Twople("a", "b"),
y = x;
x == x // false
x == y // false
Whereas the non-generic version:
value record TwoStrings(String a, String b);
TwoStrings x = new TwoStrings("a", "b"),
y = x;
x == x // true
x == y // true
So I think what this does is just move the surprise to where you don't
trip over it 100% of the time, but you still trip often enough that you
curse it.
On 2/20/2019 3:33 PM, Remi Forax wrote:
I still think we have not finished exploring how to implement acmp for value
types.
We currently have two semantics for value types:
- always return false,
- recursively compare each components
Support of acmp like the support of synchronized or System.identityHashcode is
not a part of the original model where we can just say, it should work like an
int because it's a consequence of lworld, making value types subtypes of
Object, not something inherent to the concept of value types. or said
differently, if it should work like an int, a == on value types at Java level
should be converted to a vcmp (like there is an icmp_*) which is not an answer
to how acmp is supposed to work.
The issue with the first semantics is that it will be very surprising and will
not be compatible with all the existing codes that only use == instead of a ==
followed by a call to equals().
The issue with the second semantics is that it's an unbounded computation,
shaking the Java performance model everybody has in mind by moving == from one
of the fastest operation to a potentially very slow operation.
I wonder if there is not a intermediary semantics, return false if one field is
an Object or an interface or do a component wise comparison otherwise ?
For value types like Point, Complex, == is the component wise comparison, for a
value type that works like Optional, == return false.
It seems not that bad but it means that doing an == on a wildcard of a reified
generics like Atomic<T> depends on the class of T at runtime ?
Rémi
