<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="line-break:after-white-space"><div style="font-family:Helvetica,Arial;font-size:13px"><div style="margin:0px">I was going to bring up equals() and operator overloading like Stephen, but for a completely different reason, so here goes… Brian’s said in the past that an operator notation for equals() is probably not a priority right now. But I think there’s strong reasons for adding it _at the same time_ as Valhalla, and IMHO there’s also a good notation available:</div><div style="margin:0px"><br></div><div style="margin:0px">- With Valhalla developers will gleefully start using == with their new value classes (I know I will). Because (a) they’ll be regarded as ‘user-defined primitives’, (b) x.equals(y) is so awkward, let alone !x.equals(y), (c) == may be seen as potentially faster than equals().</div><div style="margin:0px"><br></div><div style="margin:0px">- The catch, as we know, is that == _usually_ does what we want for value classes (which is basically equals()), but usually doesn’t when there are identity fields. So each class has to document == somewhere as if it’s a method without a predictable meaning.</div><div style="margin:0px"><br></div><div style="margin:0px">Case in point: if Color were a value class, many would assume they can use == for equality, but that wouldn’t work if the RGBA are stored in an array. IMHO the solution has to be to wean developers off == and onto a new equals() operator, not to tell them to take more care reading the class’s Javadoc. It’s too risky.</div><div style="margin:0px"><br></div><div style="margin:0px">But no operator seems ideal since = isn’t available: I think that’s why we are where we are. However… I’d suggest === and (say) =/= would work well if IDEs are encouraged to _display_ them as the equivalence symbols ≡ and ≢ (U+2261/2262), which IntelliJ IDEA already does. They’re attractive and make mathematical sense: see various uses in <a href="https://en.wikipedia.org/wiki/Triple_bar">https://en.wikipedia.org/wiki/Triple_bar</a> . Possibly even allow ≡ in source code too - Java is the original Unicode-based language, after all…</div><div style="margin:0px"><span class="Apple-tab-span" style="white-space:pre"> </span></div><div style="margin:0px">If this seems just too novel, it could be pointed out that C’s == never made sense as a math notation and != even less. I see x ≡ y (typed as x === y) as a clear upgrade from x == y, let alone from x.equals(y). It could also open the door for other Unicode operators in future.</div><div style="margin:0px"><br></div><div style="margin:0px">Jonathan</div></div><div><div>Jonathan Finn</div><div><br></div></div><div class="gmail_signature"></div> <br><p class="airmail_on">On 11 March 2024 at 22:38:34, Stephen Colebourne (<a href="mailto:scolebourne@joda.org">scolebourne@joda.org</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>Is there a plan for operator overloading in Valhalla? As far as I'm
<br>aware there isn't a public plan, and I'm not asking for one in
<br>response to this email. Instead I'm asking if a plan is likely in the
<br>future and how it fits into Valhalla timescales.
<br>
<br>I raise this because of the issue with the meaning of == on
<br>Float/Double value types. Bitwise comparison is absolutely fine and
<br>correct for a JVM-level sameness test. But it is *never* what a
<br>developer wants when writing a business application, hence discussion
<br>of alternative approaches such as normalization.
<br>
<br>If == was spelled differently (such as an `Objects.same(a, b)` method)
<br>then the recent debate would be irrelevant. But the current proposal
<br>is:
<br>- the only equals operator is spelled ==
<br>- it works 100% correctly for numeric value types including
<br>Float/Double except for the NaN edge cases
<br>Given these two facts, == *will* be widely used as the equals operator
<br>irrespective of the authors' wishes. Just as it is for Enum and Class
<br>objects. This will inevitably lead to bug reports where == on two
<br>different NaN returns false.
<br>
<br>As such, I raise the question as to whether there is any kind of plan
<br>or priority to provide an operator mapping to Object.equal() for all
<br>types in Java, not just value types. If you can say that there is such
<br>a plan, then the == on Float/Double issue mostly goes away.
<br>
<br>Stephen
<br></div></div></span></blockquote></body></html>