valhalla-dev Digest, Vol 7, Issue 24

Vitaly Davidovich vitalyd at
Fri Jan 9 16:42:58 UTC 2015

Honestly, it's going to be terrible if people can't provide their own
equals/hashCode for value types.  What's the rationale for that?

Also, special casing == for just value types doesn't seem appealing as it
muddies the water and when I see == in code I have to go check whether it's
value types or not to figure out what's going to happen.

Sent from my phone
On Jan 9, 2015 11:37 AM, "Simon Ochsenreither" <simon at>

> > As a possible implementation strategy:
> >  - have == simply translate to invocation of .equals() for values
> >  - have compiler/VM generate componentwise equals/hashCode
> >  - maybe, or maybe not, permit developer to override said equals
> The combination of 1 and 3 sounds terrible, imho. :-)
> a) Until now, people could expect that == had a fixed, non-changeable
> interpretation. With that strategy, it could do arbitrary things.
> b) Additionally it conflates two different concepts: Low-level identity
> and high-level equality.
> c) Plus, with references we had to worry whether equals was implemented
> or was just using the default implementation of pointer identity. With
> that strategy we would create the reverse problem: Using ==, we would
> have to wonder whether it was just the default implementation or someone
> overrode it.
> What's wrong with the strategy I proposed earlier?

More information about the valhalla-dev mailing list