valhalla-dev Digest, Vol 7, Issue 24

[Brian Goetz]

Yes, this is the plan.

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



> What's wrong with giving == and != a sensible implementation for value
> types as mentioned earlier? This would avoid introducing a new concept
> and would not require rewriting every equals/contains/... method in
> existence.
>
>
>>> b) How is this different to the approaches already outlines earlier?
>>
>> It provides a basic logical building-block (equality check) at the
>> language level, in a way that works both for primitives/valuetypes and
>> for nullable references. It addresses a very big long-standing pain
>> point in Java application development. It avoids writing/ or encouraging
>> "Duck.woof()" style-hacks -- null checks -- into a domain that does not
>> uniformly support them.
>
> Isn't this what was proposed earlier, just with == instead of
> introducing a new operator?
>