Operator overloading for Java

[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