What you need is language-defined support for decimal types and the use of operator symbols such as + on those types, not a general purpose operator overloading mechanism for all user-defined types. The problem with operator overloading is that there really aren’t many good use cases for this. Decimals are one. Complex numbers are another. There are others, but they are increasingly obscure.

Whether a language chooses to support a feature or not does not inherently make it dirty or clean. It’s a feature that you may either choose to use or not. Personally I think this whole topic would go away if there was a proper decimal native type in Java. That’s my need at the moment and BigDecimal (being the abomination that it is) makes using java for a project I’m on untenable. I would love to use Java but until there is a native decimal type so I can code a = N * 10.5 + 3.25 rather than a = n.multiply(new BigDecimal(10.5) + new BigDecimal(3.25)) I will have to use C#. Any other argument is pointless because it doesn’t change that basic fact.

Steve

Now how would I recommend that operator overloading be added to the language in such a way that it wouldn’t be abused? Unfortunately, as another poster remarked, it’s just as easy for a lazy programmer to name a function plugh() as it is for somebody to abuse an otherwise useful feature like operator overloading to create code that is not easily understood. I suspect that adding a notion of const-correctness to java and requiring that overloaded operators observe such correctness on their parameters would help matters somewhat, but of course I’m sure that even that could probably be hacked around.

However, as has been admitted by many people here, there are many use cases where certain overloads absolutely make sense, and where the lack of these overloads makes using these objects in Java quite obnoxious: BigDecimal, BigInteger, vectors, complex numbers, matrices, and quaternions are the ones that people are usually thinking of when they beg for operator overloading.

There’s an obvious solution here: if giving us operator overloading hurts too much (I’m not entirely convinced, but…), we could at least be provided with Magic Objects (like String) for each of these important and commonly used types, and have the compiler specially add that syntax sugar. That adds some new syntax, so it will probably never happen, but it seems like an extremely reasonable solution to me…

My proposal for (dual) operator overloading is such:
1.The result is returned.
2.No object instance is mutated.

1 is obvious. 2 could be enforced by the compiler – at least I’m sure it could. Just make assignments to this.* invalid. This rids you of the problem (which is, in fact, there in C++ as well). [Granted, there may be ways to do it by side-effects, but hey!, in complex languages like Java you can always work-around something. And if it's by reflection...]
Of course, never anybody will be able to keep dumbheads from inventing strange uses for specific operators. But I’ve seen similar things with named methods.

And there’s oh so many uses for operator overloading. After Java5, it’s the one thing I always said is missing from Java to make it a great programming language. Remember generics? Done mainly with preprocessor in C – baaad. Great implementation in Java. Why not try to do it the same way in Java, getting rid of the problems. Granted, there may be more to it than my two cents above, but that already rids you of one ambiguity…

It does come back to what one means by “+”, thus proving the point that overloading is a loaded subject. If by “+” database rows (they ain’t records) we mean accumulate the total, then yes, COBOL-ers do it all the time as described, and would appreciate such an overload. It would make their lives easier; just ask anyone who’s written an AP module. On the other hand, if “+” database rows means the set of rows meeting the result of multiple statements, that exits with UNION, and MINUS has been implemented as EXCEPT in some database. My error. I don’t have cause to use it.

As Alx said, “+” is defined for matrix operations. This definition is universal within the profession. If you’re a mathematician, you have a definition. Overloading of operators within the scope of one program, or even a suite of programs is a different kettle of fish.

Overloading requires knowing (at least) four things: the complete semantics of the operator in its base (original, as far back as we can trace) context, the complete semantics of that context, the exactly equivalent semantics proposed for the operator in the context of code being created, and that a person of average intelligence would find the result of the overload intuitive. That really is a tall order. And likely why only “+” in java; that and the fact that the convention already existed. hmm.

It seems to me that they are adding records to a collection of records. The + sign usually suggests that there are two “quantities” of similar type and the result of the operation is another quantity of similar type. Also, it is implicit that there is no general way to uniquely decompose the result into the two original quantittes.

The use of “+” for accumulating database records has a slightly different meaning. Yes, we do add a record to a collection of records, but there the similarity ends. The two “quantities”, record and collection of records are not of the same type; and it is possible to get back the “last” record added if it is an ordered set.

Hence, the “+” sign should not be used as a shortcut for accumulating records to a collection of records. Although permitted by COBOL conventions, I would definitely not use it.

Have you ever had to maintain code that misused language features? You can’t enforce developers to ‘correctly’ use language features. While misuse of language features isn’t a valid reason for not implementing a specific feature I’d argue it’s a smart one.