Is operator overloading in the Valhalla plan?

[Stephen Colebourne]

On Tue, 12 Mar 2024, 19:29 Brian Goetz, <brian.goetz at oracle.com> wrote:

> Without diving into operator overloading, I think you have this bit
> backwards:
>
> On 3/11/2024 6:38 PM, Stephen Colebourne wrote:
>
> == *will* be widely used as the equals operator
> irrespective of the authors' wishes. Just as it is for Enum and Class
> objects. This will inevitably lead to bug reports where == on two
> different NaN returns false.
>
>
> But, this is not the case; there is no case where float== says any NaNs
> are equal to any other, even themselves.  Float== treats _all_ NaNs as
> unequal, even the same NaN bit pattern, even the same variable (f == f).
>

Not sure why you think my original mail was discussing primitive type float
==. It wasn't. It was discussing the behaviour of java.lang.Float/Double
once converted to a value type.

The anomaly created by the proposed Object== semantics is that a value type
> with a float field may treat the two as Object==, when the component fields
> are not float==, because float== uses neither bitwise nor representational
> equivalence, regardless of NaN bit patterns.
>

Given the current state of Valhalla, I believe that this code always works
and operates in a sensible way except for java.lang.Float/Double wrt odd
NaNs:

  SomeNumericValueType a = loadA();
  SomeNumericValueType b = loadB();
  if (a == b) {
    // do something when equal
  }

At no point does this example refer to == on primitive float/double (where
the language is forever screwed). The key point is that code like that
above will be widely adopted and considered correct. I do not believe you
will convince developers to use a.equals(b) in numeric scenarios like that
above.

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240312/4c2ade20/attachment.htm>