Value equality

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Valhalla Expert Group Observers" <valhalla-spec-observers at openjdk.java.net>
> Cc: "Kevin Bourrillion" <kevinb at google.com>
> Envoyé: Lundi 16 Mai 2016 21:00:37
> Objet: Re: Value equality
> 
> 
> > another possible choice is to not allow == on value type (and on a T bound
> > by any),
> > it makes the semantics far easier to understand, you can only use == on
> > something which fit into a 32/64 bits,
> > in that case primitive types need to have an equals.
> >
> 
> This wouldn't go well when migrating existing generic code to
> any-generic.  Consider code like:
> 
> class Bag<T> {
>      void contains(T t) {
>          for (T e : this)
>              if (t == e || t.equals(e))
>                  return true;
>          return false;
>      }
> 
> When we anyfy this code, if == were not allowed on values, this code
> would break.  (You might suggest in this case we constant-fold it to
> false, but that is not likely to seem intuitive either.)

t == e is here just because equals() can be slow (or not inlined),
premature optimization is the root of Evil :)

> 
> Would be nice to minimize the amount of change to anyfy this case,
> beyond sticking an 'any' in front of T -- existing well-behaved generic
> code should require little or no change (for some definition of
> 'well-behaved').
> 
> 
> 

I'm not sure to buy that we should add == to value type because it will make migration easier.

Rémi