Updated State of the Specialization

[Brian Goetz]

You're on the right track, but I think bitwise is the wrong answer; I 
think the right answer is applying == componentwise.  Otherwise, if I 
have a value type:

value class DoubleHolder {
     double val;
}

DoubleHolder d1 = "new" DoubleHolder(NaN);
DoubleHolder d2 = "new" DoubleHolder(NaN);

Under a componentwise ==, I get d1 != d2, just as I would with two 
double values, but under a bitwise, I get d1 == d2.  This is exactly the 
asymmetry I think you're trying to avoid!  Better to apply the rule that 
two values are == iff all their components are ==.

But you say "default equals()".  Do you think this should be 
overridable?  Or should this just be what == means, just as it does for int?

> I think default .equals() method for value types should be the bit-wise
> compare of all fields. I think this is a very important canonical equals
> and hard to implement in custom method easily (because of peculiarities
> of float and double). Like default equals for reference types, it is an
> equivalence relation with the greatest possible number of equivalence
> classes. The default .hashCode() method could then be some quick
> bit-wise sum of public fields. If there are no public fields, it would
> simply be 0. Value types holding sensitive information would then have
> to contain some public uniquifying field if they wanted to be used as
> keys in hash maps or implement a secure hash algorithm if they hold
> enough entropy.
>
> Regards, Peter