Is operator overloading in the Valhalla plan?

[Joseph D. Darcy]

FYI, for some additional context, a discussion was added to 
java.lang.Double a few release ago on the different kinds of 
equivalence-like relationships that are useful to define over 
floating-point values: numerical equality, bit-wise equivalence, and 
representation equivalence.

https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Double.html#equivalenceRelation

HTH,

-Joe

On 3/12/2024 12:29 PM, Brian Goetz 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).
>
> 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.  But 
> we will see such anomalies whether we pick representational or bitwise 
> comparison for values, because float== is already weird.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240312/b340f0f9/attachment.htm>