Equality (was: Re: Migrating methods in Collections)

[Brian Goetz]

> 1. It seems unresolved in the current State of Values doc
> whether value types will have user-definable equals()
> methods. I think that this needs to be settled soon:
>
> If value types don't allow overriding equals, and if the implementation
> is "has same type and bits", then some of the problems you note
> almost disappear. For example c.contains(x) could be automatically
> translated into "false" if c is a collection of a different val type
> than x, or x is a ref type or null. Which also happens to catch all
> the type-problematic cases. I'm not sure how a compiler would know
> to do this though.

Here's the current thinking on the tools for equality:

  - The bytecode set will provide sort of 'vcmpeq' instruction, whose 
behavior is a componentwise recursive comparison (int fields with icmp, 
value fields with vcmp, etc).
  - The == operator in the language will correspond to vcmpeq
  - The default (whether provided by javac or VM) implementation of 
equals(V) for value types will do an == comparison
  - Users can override equals(V)

The motivation for allowing overriding equals is the same as for 
objects.  Obvious examples include Decimal(1.0) and Decimal(1.00), and 
Tuple[String,String] that both contain [ foo, bar ] but use different 
String instances to do so.

On the signature of equality, equals() has potentially the same issue as 
contains(), where you might want to accept a broader set of comparands. 
  Still figuring out the options there.