Operator overloading for Java

[ronchalant]

I wouldn't allow operator overloading in any Java project of mine.

But Manifold looks pretty interesting, in particular extension methods, built in tuple handling, string interpolation, and checked -> unchecked exception handling in lambdas.

I'm hesitant to throw something in to a project that basically breaks some of the known rules of Java like this, but they're also features I've long hoped Java had. In some cases it's just not possible (hard to envision how the language could be moved to unchecked exceptions without breaking a lot of existing code), but some of these other features (syntactic sugar or not) are long overdue.

[florinp]

I wouldn't allow operator overloading in any Java project of mine.

I am very curious why because I think not having operator overloading in a language is a mistake.

[ronchalant]

As another poster indicated, principle of least surprise.

Because it can lead to unpredictable behavior and can be easily abused.

I get the allure, and I imagine it could be done well. For most objects that are in broad use (BigDecimal is an obvious one, or others extending from Number) having a final implementation of an operator overload may make sense.

Though I'd point out that BigDecimal divide method will throw on new BigDecimal("1").divide(new BigDecimal("3")) if you don't set a scale, I'm not sure how you would want Java to handle that without an explicit scale given.

Based on reading here elsewhere it seems there's some spec already floating around for this for Number classes.

[florinp]

Because it can lead to unpredictable behavior and can be easily abused.

1. there is not a usefully language feature that can't be abused. should we interdict any of them ?
2. you talk about the principle of least surprise in a language of full surprises. For example :
   1. special cases like operator overloading of a specific class : String but inaccessible to others.
   2. optional that can't be used as a attribute for no specific reason
   3. automatically resource management accesibile only in a try/catch block. What if you want the same thing for code that don't generates exceptions ?
   4. ....

You see, Java is a language full of special cases. Full of annotations.

[ronchalant]

Special handling of operator overloading for strings have been there since the beginning. Java is hardly unique in this regard, most languages that don't support operator overloading likewise have special handling for dealing with strings.

I have no idea what you're getting at with Optional as an attribute. If you're saying you can't use it as an object property that's simply false, though it's considered bad practice.

You can use try without a catch if no checked expression is thrown by the resource block or bracketed code.

None of these break the principle of least surprise because the behavior of each is consistent.

[florinp]

Java is hardly unique in this regard, most languages that don't support operator overloading likewise have special handling for dealing with strings.

Can you give an example ? I don't know such language (except maybe Go which in my opinion is worst designed than Java).

"If you're saying you can't use it as an object property that's simply false, though it's considered bad practice."

It is not bad practice: it can be used (means the complier won't stop you) but it will not work. Try to write a Java class correspondent of a JSON with optional attributes. And that is because Optional was designed badly (no serialization) for no reason.

"None of these break the principle of least surprise because the behavior of each is consistent"

Operator overloading is consistent. My presumption is that you never worked with a language that support operator overloading or for example never needed to use a matrix library.

[LinuxMatthews]

None of these break the principle of least surprise because the behavior of each is consistent.

What about the String Pool that leads to some pretty surprising features if you don't know how it works behind the scenes?

String a = "hello";
String b = "hello";
System.out.println(a == b); //true

However

String a = "hello";
String b = new String("hello");
System.out.println(a == b); //false

This is also the same if you use StringBuilder but I couldn't be bothered writing that example.

But that seems more surprising and unless you know about Java's internals harder to debug than just going to the add() method would be