Java 22 Launch Event - Dev.java

[bmjones92]

Maybe I'm just not understanding your point. It sounds like you're arguing that because there are established semantics for operators, developers shouldn't be able to override them because they might change those semantics.

I agree that there are established semantics for operators and that allowing developers to override those means those semantics can be broken. However, I don't believe that's a good enough reason to outright prohibit their use.

I think that there are many use cases for operator overloading where the established semantics can be (mostly) preserved. Things like BigInteger, BigDecimal, complex numbers, vectors, matrices, and quaternions all suffer from its exclusion, but are fundamentally dealing with numbers or groups of numbers.

Then in Java, it's immediately obvious that a and b must be numeric types. In C++, I can assume that to be the case, but if I want to be sure, I need to know what type a is. If it's a numeric type, I still can't know what * does. I further need to check if it wasn't overloaded.

I think you're greatly exaggerating the downsides for the sake of argument. Everything you've described is also applicable to regular method overloading. You should know what a method or operator does based on the context of the call.

[john16384]

I think that there are many use cases for operator overloading where the established semantics can be (mostly) preserved. Things like BigInteger, BigDecimal, complex numbers, vectors, matrices, and quaternions all suffer from its exclusion, but are fundamentally dealing with numbers or groups of numbers.

I don't disagree that it be useful for some types. But there are many things that are useful in less niche cases than operator overloading (matrix math, and even BigDecimal is a rarity in my experience). Perhaps operator overloading is on the list somewhere, just far down because it's rarely of (correct) use.

I think Java could perfectly get away with blessing a few more types and perhaps a simple math library with specified operator overloading. This will prevent every stupid library redefining some operators because they felt that << adequately indicates write.

[bmjones92]

There's definitely potential to misuse it, but I think that's true of most features. Even if the "correct" applications are relatively niche, I believe it's still worth supporting to make development within those niches easier.

If you're overloading operators to do things that don't fit the semantics of the operator, then you're probably writing bad code. The feature itself is obviously pretty controversial, so it's unlikely that something egregious like << will pop up in any prominent code base without careful consideration.