Is operator overloading in the Valhalla plan?

[Brian Goetz]

You are right that developers will frequently do dumb things in search 
of concision or perceived performance advantage, but I don't think 
that's a compelling argument for "so then let's create yet another 
spelling for equality".

But, underlying the concern you raise is that developers are frequently 
put in the position of worrying whether to use `==` or `.equals()`.  One 
thing Valhalla does do to make this better, but in a perhaps surprising 
way, is that it makes it practical to just always use equals().

Consider implementing the equals() method of a class like:

     class C {
        int i;
        String s;

        public boolean equals(Object other) {
            return other instanceof C c
                && i == c.i
                && s.equals(c.s);
        }
     }

Until Valhalla, there is no equals method to call on `int`, so using 
`==` for int and `.equals()` for String is the only semantically correct 
move -- and this asymmetry is irritating. But with Valhalla, you can write:

            return other instanceof C c
                && i.equals(c.i)
                && s.equals(c.s);

without fear of "oh, but that means I am going to box, which is dumb".  
The int::equals call will unroll to a simple bitwise field comparison, 
and we can now happily write our equals methods uniformly to use 
`.equals()` 99% of the time, and only when identity really matters do we 
fall back to `==`.

Now, this doesn't do anything for "but I want to type this with as few 
characters as possible", but not having to think about either "which 
comparison do I have to use" (most of the time) and the perceived cost 
of boxing (most of the time) is surprisingly freeing.

If in ten years we decide we still want `===` as a shorthand, it becomes 
purely a syntactic decision, separated from all the accidental 
considerations.  Ask me again then!


On 3/12/2024 3:14 PM, Jonathan F wrote:
> 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/6962cac0/attachment.htm>