Is operator overloading in the Valhalla plan?

[Jonathan F]

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:

- 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().

- 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.

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.

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
https://en.wikipedia.org/wiki/Triple_bar . Possibly even allow ≡ in source
code too - Java is the original Unicode-based language, after all…
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.

Jonathan
Jonathan Finn


On 11 March 2024 at 22:38:34, Stephen Colebourne (scolebourne at joda.org)
wrote:

Is there a plan for operator overloading in Valhalla? As far as I'm
aware there isn't a public plan, and I'm not asking for one in
response to this email. Instead I'm asking if a plan is likely in the
future and how it fits into Valhalla timescales.

I raise this because of the issue with the meaning of == on
Float/Double value types. Bitwise comparison is absolutely fine and
correct for a JVM-level sameness test. But it is *never* what a
developer wants when writing a business application, hence discussion
of alternative approaches such as normalization.

If == was spelled differently (such as an `Objects.same(a, b)` method)
then the recent debate would be irrelevant. But the current proposal
is:
- the only equals operator is spelled ==
- it works 100% correctly for numeric value types including
Float/Double except for the NaN edge cases
Given these two facts, == *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.

As such, I raise the question as to whether there is any kind of plan
or priority to provide an operator mapping to Object.equal() for all
types in Java, not just value types. If you can say that there is such
a plan, then the == on Float/Double issue mostly goes away.

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