acmp again !

[Remi Forax]

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