Equality

[Brian Goetz]

> Anyfy equals, and adjust default implementation of boolean T.equals(any x)

I think we may be talking past each other (while basically saying the 
same thing from opposite directions.)

"any" is not a type; it is a modifier that affects the domain of type 
variables.  So we don't have (and I think we don't want) a meaning for 
equals(any x).  But what we do want, is a way of expressing "I'll take 
anything which could be on the other side of the == operator with me." 
For refs, that's Object; for a value type V, that's just V.

Where we had gotten with the <V super U> / superation idiom (not 
suggesting either of these syntaxes is great) is being able to express:

  - If T is value, then T, else the erasure of T (usually object) **

I'll write this as Sup<T> for short.  The convenient thing about Sup<T> 
is that it conveniently collapses to Object in the places where we want 
Object, so we could define contains/remove as

   contains(Sup<T>)

and contains will always bottom out at equals(), so equals() similarly 
needs to be

   equals(Sup<Self>)

If this is a valid approach (and I think its the best one we've got so 
far), then we're looking for how to spell Sup<Self> (in all of: type 
system, language syntax, bytecode descriptors.)

> I still think that doing something like this removes the need
> to specially deal with Collection.contains and related methods.

I don't see it yet; those signatures are still currently 
contains(Object), which isn't appropriate for value types.  So we have 
to do *something*.




** There's a lot of sloppiness in the ref/val distinction, which is 
going to need to be cleaned up.  Sometimes when we say ref/val, we mean 
"erased/reified".  Sometimes we mean "polymorphic/monomorphic". 
Sometimes we mean "nullable/non-nullable."